Оригинальный документ (pdf) | Перевод с помощью сервиса Google Translate

Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) (Draft)

Recommendations of the National Institute of Standards and Technology

Erika McCallister Tim Grance Karen Scarfone

Special Publication 800-122 (Draft)

Executive Summary 

Breaches of personally identifiable information (PII) have increased dramatically over the past few years and have resulted in the loss of millions of records.¹ Breaches of 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 high costs to handle the breach. 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 the broad definition of PII from OMB Memorandum 07-16⁵ to identify as many potential sources of risks related to PII as possible. OMB defined PII as “information which can be used to distinguish or trace an individual's identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.” Examples of PII include, but are not limited to:

• Name, such as full name, maiden name, mother’s maiden name, or alias
  
• Personal identification number, such as social security number (SSN), passport number, driver’s license number, taxpayer identification number, or financial account or credit card number
  
• Address information, such as street address or email address
  
• Personal characteristics, including photographic image (especially of face or other distinguishing characteristic), fingerprints, handwriting, or other biometric image or template data (e.g., retina scans, voice signature, facial geometry).

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 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 the 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:

•  Distinguishability. Organizations should evaluate how easily the PII can be used to distinguish particular individuals. For example, an SSN uniquely identifies an individual, whereas a telephone area code could map to many people.
  
• Aggregation and Data Field Sensitivity. Organizations should evaluate the sensitivity of each individual PII data field, as well as the sensitivity of the PII data fields when combined. For example, an individual’s SSN or financial account number is generally more sensitive than an individual’s phone number or zip code. Similarly, the combination of an individual’s name and financial account number is more sensitive than the individual’s name alone.
  
• Context of Use. Organizations should evaluate the context of use, which is the purpose for which the PII is collected, stored, used, processed, disclosed, or disseminated. The context of use may cause identical PII data elements to be assigned different PII confidentiality impact levels based on their use. For example, suppose that an organization has two 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, and the second list is people who work undercover in law enforcement. The potential impacts to the affected individuals and to the organization are significantly different for each list.
  
• Obligations to Protect Confidentiality. An organization that is subject to any obligations to protect PII should consider such obligations when determining the PII confidentiality impact level. Obligations to protect generally include laws, regulations, or other mandates (e.g., Privacy Act, OMB guidance). For example, some Federal agencies, such as the Census Bureau and the Internal Revenue Service (IRS), are subject to specific legal obligations to protect certain types of PII.⁶
  
• Access to and Location of PII. Organizations may choose to take into consideration the nature of authorized access to and the location of the PII. When PII is accessed more often or by more people and systems, or the PII is regularly transmitted or transported offsite, then there are more opportunities to compromise the confidentiality of the PII.

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 the 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 general protection measures, privacy-specific protection measures, and security controls⁷ used for other types of information, such as:

• Creating Policies and Procedures. Organizations should develop comprehensive policies and procedures for protecting the confidentiality of PII.
  
• Conducting Training. Organizations should reduce the possibility that PII will be accessed, used, or disclosed inappropriately by requiring that all individuals receive appropriate training before being granted access to organization information systems.
  
• De-Identifying PII. Organizations can de-identify records by removing enough PII 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 records can be used when full data records are not necessary, such as for examinations of correlations and trends.
  
• Using Access Enforcement. Organizations can control access to PII through access control policies and access enforcement mechanisms (e.g., access control lists).
  
• Implementing Access Control for Mobile Devices. Organizations can prohibit or strictly limit access to PII from portable and mobile devices, such as laptops, cell phones, and personal digital assistants (PDA), which are generally higher-risk than non-portable devices (e.g., desktop computers at the organization’s facilities). Organizations may choose to forbid all telework and remote access involving higher-impact instances of PII so that the information will not leave the organization’s physical boundaries through telework activities.
  
• Providing Transmission Confidentiality. Organizations can protect the confidentiality of transmitted PII. This is most often accomplished by encrypting the communications or by encrypting the information before it is transmitted.
  
• Auditing Events. Organizations can monitor events that affect the confidentiality of PII, such as inappropriate access to PII.

Organizations should minimize the 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 of PII is greatly reduced if an organization minimizes the amount of PII it collects and stores. Organizations should limit PII collection and retention to the least amount necessary to conduct their business purpose and mission. For example, an organization should only request PII on 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-16 specifically requires agencies to:

• Review current holdings of PII and ensure they are accurate, relevant, timely, and complete
  
• Reduce PII holdings to minimum necessary for proper performance of agency functions
  
• Develop a schedule for periodic review of PII holdings
• Establish a plan to eliminate the unnecessary collection and use of SSNs.

 

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

Breaches of 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 PII breaches. Organizations should develop plans⁹ that include elements 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 policies.

Organizations should encourage close coordination among their privacy officers, chief information officers, 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 PII breaches by ensuring proper interpretation and implementation of requirements.

1. Introduction

1.1 Authority

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.

1.2 Purpose and Scope

The purpose of this document is to assist Federal agencies in protecting the confidentiality of a specific category of data commonly known as personally identifiable information (PII). 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 breaches involving PII. Organizations are encouraged to tailor the recommendations to meet their specific requirements.

1.3 Audience

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, compliance officers, system administrators, chief information system security officers, information system security officers, information security support staff, computer security incident response teams, and chief information officers.

1.4 Document Structure

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

• Section 2 provides an introduction to PII and lists some basic requirements involving the collection and handling of PII.
• Section 3 describes factors for determining the potential impact of inappropriate access, use, and disclosure of PII.
  
• Section 4 presents several methods for protecting the confidentiality of PII that can be implemented to reduce PII exposure and risk.
• Section 5 provides recommendations for developing an incident response plan for breaches involving PII and integrating the plan into an organization’s existing incident response plan.

The following appendices are also included for additional information:

• Appendix A provides samples of PII-related scenarios and questions that can be adapted for an organization’s exercises.
  
• Appendix B presents frequently asked questions (FAQ) related to protecting the confidentiality of PII.
  
• Appendix C contains definitions of common general terms related to private information.
  
• Appendix D provides additional information about the Fair Information Practices that may be helpful in understanding the framework underlying most privacy laws.
  
• Appendix E contains a FAQ pertaining to logging and verifying sensitive database extracts.
  
• Appendix F provides a glossary of selected terms from the publication.
  
• Appendix G contains a list of acronyms and abbreviations used within the publication.
  
• Appendix H presents a list of resources that may be helpful to individuals in gaining a better understanding of PII, PII protection, and other related topics.

 

2. Introduction to PII

One of the most broadly used terms to describe personal information about individuals 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 impact both individuals, by contributing to identity theft, and the organization, by reducing public trust in the organization. In many cases, it may not be clear to the professionals responsible for protecting information which instances of PII need additional confidentiality protection and at what level. This section explains how to identify and locate PII11 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 protection measures, respectively. Section 5 discusses incident response for breaches involving PII.

2.1 Identifying PII

This publication uses the definition of PII from OMB Memorandum 07-16,¹² which is “information which can be used to distinguish or trace an individual's identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.”

To distinguish an individual¹³ is to identify an individual. Some examples of information that could distinguish an individual include, but are not limited to, name, passport number, social security number, or biometric image and template. In contrast, a list containing only credit scores does not have sufficient information to distinguish a specific individual.

Information elements that are linked or linkable are not sufficient to distinguish an individual when considered separately, but which could distinguish individuals when combined with a secondary information source. For example, suppose that two databases contain different PII elements and also share some common PII elements. An individual with access to both databases may be able to link together information from the two databases and distinguish individuals. If the secondary information source is present on the same system or a closely-related system, then the data is considered linked. If the secondary source is available to the general public or can be obtained, such as from an unrelated system within the organization, then the data is considered linkable. Linked data is often de-identified in some way (as described in Section 4), and information that makes re-identification possible is available to some system users. Linkable data is also often de-identified, but the remaining data can be analyzed against other data sources, such as telephone directories and other sources available to large communities of people, to distinguish individuals.

Organizations should use a variety of methods 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). 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 information system. PTAs are used to determine if a system contains PII, whether a Privacy Impact Assessment is required, whether a System of Records Notice (SORN) is required, and if any other privacy requirements apply to the information system. PTAs should be submitted to an organization’s privacy office for review and approval. PTAs are often comprised of simple questionnaires that are completed by the system 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, or checking with system owners.

2.2 Examples of PII Data

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

• Name, such as full name, maiden name, mother’s maiden name, or alias
  
• Personal identification number, such as SSN, passport number, driver’s license number, taxpayer identification number, patient identification number, and financial account or credit card number¹⁶
  
• Address information, such as street address or email address
  
• Asset information, such as Internet Protocol (IP) or Media Access Control (MAC) address or other host-specific persistent static identifier that consistently links to a particular person or small, well- defined group of people
  
• Telephone numbers, including mobile, business, and personal numbers
  
• Personal characteristics, including photographic image (especially of face or other distinguishing characteristic), x-rays, fingerprints, or other biometric image or template data (e.g., retina scans, voice signature, facial geometry)
  
• Information identifying personally owned property, such as vehicle registration or identification number, and title numbers and related information
  
• Information about an individual that is linked or linkable to one of the above (e.g., date of birth, place of birth, race, religion, weight, activities, or employment, medical, education, or financial information).
  

2.3 PII and Fair Information Practices

The protection of PII and the overall privacy of records are concerns both for individuals whose personal records are 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 privacy laws, is based on the widely- recognized Fair Information Practices, also called Privacy Principles. There are five core Fair

Information Practices¹⁸ that are based on the common elements, or privacy principles, of several international reports and guidelines. These core practices are as follows:

• Notice/Awareness - Individuals should be given notice of an organization’s information practices before any personal information is collected from them.
  
• Choice/Consent - Individuals should be given a choice about how information about them is used.
  
• Access/Participation - Individuals should have the right to access information about them and request correction to ensure the information is accurate and complete.
  
• Integrity/Security - Data collectors should ensure that information is protected by reasonable security safeguards against such risks as loss or unauthorized access, destruction, use, modification or disclosure of data.
  
• Enforcement/Redress - Data collectors should be held accountable for complying with measures that give effect to the practices stated above.

For more information on the Fair Information Practices, including a summary of variations of the Fair Information Practices, see Appendix D.

3. PII Confidentiality Impact Levels

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 may also be 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. For example, malicious alterations of medical test results could endanger individuals’ lives.

The confidentiality of PII should be protected based on its risk 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 the 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.²¹

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.

 3.1 Impact Level Definitions

The harm caused from of a loss of confidentiality should be considered when attempting to determine which PII confidentiality impact level corresponds to a specific set of PII data. Harm for the purposes of this document, includes 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 civil 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 of 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 or inappropriate physical detention.

3.2 Factors for Determining PII Confidentiality Impact Levels

Determining the PII confidentiality impact level 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.

3.2.1 Distinguishability

Organizations should evaluate how easily the PII can be used to distinguish particular individuals. For example, PII data composed of individuals’ names, fingerprints, and SSNs uniquely identify individuals, whereas PII data composed of individuals’ phone numbers only would require the use of additional data sources, such as phone directories, and would only allow some unique individuals to be identified (for example, unique identification might not be possible if multiple individuals share a phone or if a phone number is unlisted). PII data composed of only individuals’ area codes and gender would not allow any unique individuals to be identified.²³ PII that is easily distinguishable may merit a higher impact level than PII that cannot be used to distinguish individuals without unusually extensive efforts.

Organizations may also choose to consider how many individuals can be distinguished from the PII data. 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 data sets than would otherwise be set. However, organizations should not set a lower impact level for a PII data set simply because it contains a small number of records.

3.2.2 Aggregation and Data Field Sensitivity

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 or financial account number is generally more sensitive than an individual’s phone number or zip code, and the combination of an individual’s name and SSN is less sensitive than the combination of an individual’s name, SSN, date of birth, mother’s maiden name, and credit card number. Organizations often require the PII confidentiality impact level to be set to at least moderate if a certain sensitive 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.

3.2.3 Context of Use

Context of use is defined as the purpose for which the PII is collected, stored, used, processed, disclosed, or disseminated, as well as how that PII is used or could potentially be used. Examples of context include, but are not limited to, statistical analysis, determining eligibility for benefits, administration of benefits, research, tax administration, or law enforcement. Organizations should assess the context of use because it is important to understanding how the disclosure of data elements can potentially harm individuals and the organization. Organizations should consider what harm is likely to be caused if the PII is disclosed (either intentionally or accidentally) or if the mere fact that the PII is being collected or used is disclosed 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 may cause multiple instances of the same types of PII data to be assigned different PII confidentiality impact levels. 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.

Examples of topics that are relevant to context of use as a factor for determining PII confidentiality impact level are abortion; alcohol, drug, or other addictive products; illegal conduct; illegal immigration status; information damaging to financial standing, employability, or reputation; information leading to social stigmatization or discrimination; politics; psychological well-being or mental health; religion; same-sex partners; sexual behavior; sexual orientation; taxes; and other information due to specific cultural or other factors.²⁴

3.2.4 Obligation to Protect Confidentiality

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

For example, a database with PII for beneficiaries of government services that retrieves information by SSN would be considered a System of Records under the Privacy Act of 1974, and the organization would be required to provide appropriate administrative, technical, and physical safeguards for the database. 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.

3.2.5 Access to and Location of the PII

Organizations may choose to take into consideration the nature of authorized access to the PII. When PII is accessed more often or by more people and systems, there are more opportunities for the PII’s confidentiality to be compromised. Another element is the scope of access to the PII, such as whether the PII needs to be accessed from teleworkers’ systems and other systems 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. PII located offsite is 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.

3.3 PII Confidentiality Impact Level Examples

The following are examples of 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.

3.3.1 Example 1: Incident Response Roster

An organization maintains a roster (in both electronic and paper formats) 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 organization makes the same types of contact information available to the public for all of its employees on its main Web site.

Distinguishability: The information directly identifies a small number of individuals (fewer than 20).

Aggregation and 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 organization’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 organization has collected or used this information is also unlikely to cause harm.

Access to and location of the PII: The information is accessed by IT staff members that 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 organization 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.

3.3.2 Example 2: Intranet Activity Tracking

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

• The user’s IP address
  
• The Uniform Resource Locator (URL) of the Web site the user was viewing immediately before coming to this Web site (i.e., referring URL)
  
• The date and time the user accessed the Web site
  
• The amount of time the user spent at the Web site
  
• The web pages or topics accessed within the organization’s Web site (e.g., organization security policy).

Distinguishability: By itself, the log does not contain any distinguishable data. However, the organization has another system with a log that contains domain login information records, which include user IDs and corresponding IP addresses. Administrators that can access both systems and their logs and took the time to correlate information between the logs could distinguish individuals. Potentially, information could be gathered on the actions of most of the organization’s users involving Web access to intranet resources. The organization has a small number of administrators that have access to both systems and both logs.

Aggregation and 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: The release of the information would be unlikely to cause harm, other than potentially embarrassing a small number of users if their identities could be distinguished. The fact that the logging is occurring is generally known and assumed and would not cause harm.

Access to and location of the 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 internal 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.

3.3.3 Example 3: Fraud, Waste, and Abuse Reporting Application

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 accusing individuals of not enforcing safety regulations. The submission of contact information is not prohibited, and individuals sometimes enter their personal information in the form’s narrative text field. The Web site is hosted by a server that logs IP address, referring Web site information, and time spent on the Web site.

Distinguishability: By default, the database does not request distinguishable data, but a significant percentage of users choose to provide distinguishable information. A recent estimate indicated that the database has approximately 30 records with distinguishable information out of nearly 1000 total records. The Web log does not contain any distinguishable information, nor could it be readily linked with the database or other sources to identify specific individuals.

Aggregation and 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. The organization does not know how sensitive this information might be to the individuals, such as unlisted phone numbers or email addresses used for limited private communications.

Context of use: Because of the nature of the submissions - 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. The ensuing harm could include blackmail, severe emotional distress, loss of employment, and physical harm. A breach would also undermine trust in the organization by both the individuals making the claims and the public.

Access to and location of the 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 own 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.

4. PII Confidentiality Protection Measures

PII should be protected through a combination of measures, including general protection measures, privacy-specific protection measures, and security controls. Organizations should use a risk-based approach for protecting the confidentiality of PII. The PII protection measures provided in this section are complementary to other general protection measures for data and may be used as one part of an organization’s comprehensive approach to protecting the confidentiality of PII.

 4.1 General Protection Measures

 This section describes two types of general PII protection: policy and procedure creation; and education, training, and awareness.

 4.1.1 Policy and Procedure Creation

Organizations should develop comprehensive policies and procedures for handling PII at the organization level, the program or component level, and occasionally the system level.30 Some types of policies include foundational privacy principles, privacy rules of behavior, policies that implement laws and other mandates, and system-level policies. The organizational privacy principles act as the foundation upon which the overall privacy program is built and 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 handing 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:

• Development of Privacy Impact Assessments (PIAs) and coordination with System of Records Notices (SORNs)
  
• Access rules for PII within a system
  
• PII retention schedules and procedures
• Redress
• Individual consent
• Data sharing agreements
• PII incident response and data breach notification
• Privacy in the System Development Life Cycle Process
• Limitation of collection, disclosure, sharing, and use of PII
• Consequences for failure to follow privacy rules of behavior.
  

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 Memorandum M-07-16 sets out specific requirements for reporting incidents involving the loss or inappropriate disclosure of PII. For additional information, see Section 5.

4.1.2 Education, Training, and Awareness

Education, training, and awareness 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:

• The definition of PII
• The basic privacy laws, regulations, and policies that apply to a staff member’s organization
• Restrictions on data collection, storage, and use of PII
• Roles and responsibilities for using and protecting PII
• Having the organization’s legal counsel or privacy officer determine legal obligations to protect PII
• Appropriate disposal of PII
• Sactions for misuse of PII
• Recognizing a security or privacy incident involving PII
• Retention schedules for PII
• Roles and responsibilities in responding to PII-related incidents.

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.

4.2 Privacy-Specific Protection Measures³²

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

4.2.1 Minimizing Collection and Retention of PII

The practice of minimizing the 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 collected and maintained, as well as the types and categories of PII 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 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 the PII is no longer relevant and necessary, then the PII should be properly destroyed. The destruction or disposal of PII must be conducted in accordance with the Federal Records Act and records control schedules approved by the National Archives and Records Administration (NARA).³⁶ The effective management and prompt disposal of PII, in accordance with NARA-approved disposition schedules, will minimize the risks of unauthorized disclosure.

4.2.2 De-Identifying Information

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 (rendered distinguishable) by using a code, algorithm, or pseudonym that is assigned to individual records. The code, algorithm, or pseudonym should not be derived from other related information about the individual, and the means of re-identification should only be known by authorized parties and not disclosed to anyone without the authority to re-identify records. A common de-identification technique for obscuring PII is to use a one-way cryptographic function, also known as a hash function, on the PII. De-identified information can be assigned a PII confidentiality impact level of low, as long as the following are both true:

• The re-identification algorithm, code, or pseudonym is maintained in a separate system, with appropriate controls in place to prevent unauthorized access to the re-identification information.
• The data elements are not linkable, via public records or other reasonably available external records, in order to re-identify the data.

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 distinguishable PII fields can be removed, and the patient ID numbers can be obscured using pseudo-random data that is linked to 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 different 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 data sets contained distinguishable identities for each person and is considered to be PII, the de-identified and aggregated dataset would not contain linked or readily distinguishable data for any individual.

4.2.3 Anonymizing Information

Anonymous is defined as something that cannot be “named or identified.” It derives from a Greek word meaning “without a name.” ³⁸ Similarly, anonymized information is defined as previously identifiable information that has been de-identified and for which a code or other link no longer exists.³⁹ Anonymized information differs from de-identified information because anonymized information cannot be re-identified. A re-identification algorithm, code, or pseudonym does not exist or has been removed and is not available. Anonymizing information usually involves the application of statistical disclosure limitation techniques⁴⁰ to ensure the data cannot be re-identified, such as: ⁴¹

• Generalizing the Data - Making information less precise, such as grouping continuous values
• Suppressing the Data - Deleting an entire record or certain parts of records
• Introducing Noise into the Data - Adding small amounts of variation into selected data
• Swapping the Data - Exchanging certain data fields of one record with the same data fields of another similar record (e.g., swapping the zip codes of two records)
• Replacing Data with the Average Value - Replacing a selected value of data with the average value for the entire group of data.

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.⁴³ Most systems that are newly developed, newly purchased, or upgraded require testing before being introduced to their intended production 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 the 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).

4.3 Security Controls

In addition to the PII-specific protection measures described earlier in this section, many types of technical and operational security controls are available to safeguard the confidentiality of PII. These controls are often already available 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.1 for a discussion of characteristics 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.

 

• Access Enforcement (AC-3). Organizations can control access to PII through access control policies and access enforcement mechanisms (e.g., access control lists). This can be done in many ways. One example is implementing role-based access control and configuring it so that each user can access only the pieces of data necessary for the user’s role. Another example is only permitting users to access PII through an application that tightly restricts their access to the PII, instead of permitting users to directly access the databases or files containing PII.⁴⁴ Encrypting stored information is also an option for implementing access enforcement.⁴⁵ OMB M-07-16 specifies that Federal agencies must “encrypt, using only NIST certified cryptographic modules, all data on mobile computers/devices carrying agency data unless the data is determined not to be sensitive, in writing, by your Deputy Secretary or a senior-level individual he/she may designate in writing”.
• Separation of Duties (AC-5). Organizations can enforce separation of duties for duties involving access to PII. For example, the users of de-identified PII data would not also be in roles that permit them to access the information needed to re-identify the records.
• Least Privilege (AC-6). Organizations can enforce the most restrictive set of rights/privileges or accesses needed by users (or processes acting on behalf of users) for the performance of specified tasks. Concerning PII, the organization can ensure that users who must access records containing PII only have access to the minimum amount of PII data, along with only those privileges (e.g., read, write, execute) that are necessary to perform their job duties.
• Remote Access (AC-17). Organizations can choose to prohibit or strictly limit remote access to PII. If remote access is permitted, the organization can ensure that the communications are encrypted.
• Access Control for Mobile Devices (AC-19). Organizations can choose to prohibit or strictly limit access to PII from portable and mobile devices, such as laptops, cell phones, and personal digital assistants (PDA), which are generally higher-risk than non-portable devices (e.g., desktop computers at the organization’s facilities). Some organizations choose to forbid all telework and remote access involving higher-impact instances of PII so that the information will not leave the organization’s physical boundaries. If access is permitted, the organization can ensure that the devices are properly secured and regularly scan the devices to verify their security status (e.g., antivirus software enabled and up-to-date, operating system fully patched).
• Auditable Events (AU-2). Organizations can monitor events that affect the confidentiality of PII, such as unauthorized access to PII.
• Audit Monitoring, Analysis, and Reporting (AU-6). Organizations can regularly review and analyze information system audit records for indications of inappropriate or unusual activity affecting PII, investigate suspicious activity or suspected violations, report findings to appropriate officials, and take necessary actions.
• User Identification and Authentication (IA-2). Users can be uniquely identified and authenticated before accessing PII.⁴⁶ The strength requirement for the authentication mechanism depends on the impact level of the PII and the system as a whole. OMB M-07-16 specifies that Federal agencies must “allow remote access only with two-factor authentication where one of the factors is provided by a device separate from the computer gaining access,” and also must “use a ‘time-out’ function for remote access and mobile devices requiring user re-authentication after thirty minutes of inactivity.”
• Media Access (MP-2). Organizations can restrict access to information system media containing PII, including digital media (e.g., CDs, USB flash drives, backup tapes) and non-digital media (e.g., paper, microfilm). This could also include portable and mobile devices with a storage capability.
• Media Marking (MP-3). Organizations can label information system media and output containing PII to indicate how it should be distributed and handled. The organization could exempt specific types of media or output from labeling so long as it remains within a secure environment. Examples of labeling are cover sheets on printouts and paper labels on digital media.
• Media Storage (MP-4). Organizations can securely store PII, both in paper and digital forms, until the media are destroyed or sanitized using approved equipment, techniques, and procedures. One example is the use of storage encryption technologies to protect PII stored on removable media.
• Media Transport (MP-5). Organizations can protect digital and non-digital media and mobile devices containing PII that is transported outside the organization’s controlled areas. Examples of protective measures are encrypting stored information and locking the media in a container.
• Media Sanitization (MP-6). Organizations can sanitize digital and non-digital media containing PII before it is disposed or released for reuse.⁴⁷ An example is degaussing a hard drive - applying a magnetic field to the drive to render it unusable.
• Transmission Confidentiality (SC-9). Organizations can protect the confidentiality of transmitted PII. This is most often accomplished by encrypting the communications or by encrypting the information before it is transmitted.⁴⁸

5. Incident Response for Breaches of PII

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

FISMA requires Federal agencies to have procedures for handling information security incidents, and it established a Federal information security incident center to coordinate and share information about incidents, which resulted in the creation of 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.

5.1 Preparation

Preparation requires the most effort because it sets the stage to ensure the PII breach is handled appropriately. Organizations should build their PII breach response plans into their existing incident response plans. The development of PII breach response plans requires organizations to make many decisions about how to handle PII breaches, 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 programs should 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 breaches of PII. The method could be a telephone hotline, email, 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 PII breach immediately at any day or time. Additionally, employees should be provided with a clear definition of what constitutes a PII breach and what information needs to be reported. The following information is helpful to obtain from employees who are reporting a known or suspected PII breach:⁵⁰

• Person reporting the incident
• Person who discovered the incident
• Date and time the incident was discovered
• Nature of the incident
• Description of the information lost or compromised
• Storage medium from which information was lost or compromised
• Controls in place to prevent unauthorized use of the lost or compromised information
• Number of individuals potentially affected
• Whether law enforcement was contacted.

Federal agencies are required to report all known or suspected breaches of PII, in any format, to US-CERT within one hour.⁵¹ To meet this obligation, organizations should proactively plan their breach notification response. A PII breach 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:

• Whether breach notification is required⁵³
• Timeliness of the notification
• Source of the notification
• Contents of the notification
• Means of providing the notification
• Who receives the notification; public outreach response.

Additionally, organizations should establish a committee or person responsible for using the breach notification policy to coordinate the organization’s response.
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.

5.2 Detection and Analysis

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 needed, 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 of PII. In the event that a suspected breach of PII is detected, Federal agencies should notify US-CERT within one hour.

5.3 Containment, Eradication, and Recovery

Existing technologies and techniques for containment, eradication, and recovery may be used for breaches involving PII. However, changes to incident handling processes may be needed, such as performing additional media sanitization steps when PII needs to be deleted from media during recovery. Particular attention should be paid to using proper forensics techniques⁵⁴ to ensure preservation of evidence for intentional criminal acts. Additionally, it is important to determine whether PII was accessed and how many records or individuals were affected.

5.4 Post-Incident Activity

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 PII breach response plan should be continually updated and improved based on the lessons learned during each incident.
Additionally, the organization should use its PII breach response policy to determine whether the organization should provide affected individuals with remedial assistance, such as credit monitoring. 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.

Appendix A - Scenarios for PII Identification and Handling

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

A.1 General Questions

1. What measures are in place to identify, assess, and protect the PII described in the scenario?
2. Which individuals have designated responsibilities within the organization to safeguard the PII described in the scenario?
3. To which people and groups within the organization should questions about PII or the possible misuse of PII be reported?
4. What could happen if the PII described in the scenario is not safeguarded properly?

A.2 Scenarios

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.

1. What information in the system is PII?
2. What is the PII confidentiality impact level? What factors were taken into consideration when making this determination?
3. By consolidating data into a single system, does it create additional vulnerabilities that could result in harm to the individual? What additional controls could be put in place to mitigate the risk?
4. Is all of the information necessary for the system to function? Is there a way to minimize the information in the system? Could PII on the system be replaced with operating data that is not PII?
5. Is the organization required to conduct a PIA for this system?

 

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:

1. Which data elements collected through this survey should be considered PII?
2. What is the PII confidentiality impact level? What factors were taken into consideration when making this determination?
3. How are determinations made as to which data from the survey are relevant to the organization’s operations? What happens to data that is deemed unnecessary?
4. What privacy-specific protection measures might help safeguard the PII collected and retained from this survey?
5. What other types of protection measures for safeguarding data (that are not necessarily specific to safeguarding PII) might be used to protect the data from the responses?

 

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’s name, 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:

1. Which data elements contained in this data extract should be considered PII?
2. What is the PII confidentiality impact level? What factors were taken into consideration when making this determination?
3. What privacy-specific protection measures might help safeguard the PII contained in the data extract?
4. What should the employee do if her purse (containing the USB drive) is stolen? What should the organization do? How could the employer have prevented this situation?
5. What should the employee do with the copies of the extract when she finishes her work?
6. Should the emailing of the extract to a personal email address be considered a breach? Should storing the data on the personal USB drive be considered a breach?
7. What could the organization do to reduce the likelihood of similar events in the future?
8. How should this scenario be handled if the information is a list of de-identified retirement income statistics? Would the previous questions be answered differently?

 

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.

1. Which data elements contained in this system test should be considered PII?
2. What is the PII confidentiality impact level? What factors were taken into consideration when making this determination?
3. What privacy-specific protection measures might help safeguard the PII used in this test?
4. Is a PIA required to conduct this testing? Is a PIA required to complete the production system upgrade?
5. What should the organization do with the data used for testing when it completes the upgrade?

Appendix B - Frequently Asked Questions (FAQ)

Privacy and security leadership and staff, as well as others within organizations, 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.

1. What is personally identifiable information (PII)?

PII is defined in OMB Memorandum M-07-16 as “information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.”

2. How does this apply to foreign nationals?

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 also 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.⁵⁸

3. What does it mean to “distinguish” an individual?

To distinguish an individual is to identify an individual. Some examples of information that could distinguish an individual include, but are not limited to, names, passport number, social security number, or biometric image and template.

4. What does it mean when a record is “linked”?

A record is linked to an individual when it contains information that cannot distinguish an individual when considered separately, but which could distinguish an individual when combined with other data elements present on the same system or a closely-related system. For example, an individual could be identified only by ID #12345 in one database, and another database on the same system could map that ID # to the individual’s name and social security number. The records in the first database would be considered “linked” if users were likely to have access to both databases, or could obtain access with minimal effort.

5. What does it mean when a record is “linkable”?

A record is linkable to an individual when it contains information that cannot distinguish an individual, but that may be matched or compared with other data elements from a source available to the general public or that is otherwise obtainable. For example, individuals might be identified in a database by home telephone number. The identities of some of the individuals could be determined by comparing this information to publicly available telephone directories.

6. Is personally identifiable information (PII) the same as information in identifiable form (IIF)?

No, the terms PII and IIF are not the same. Their definitions are distinct, cannot be used interchangeably, and have different requirements associated with them.
OMB defines PII in OMB Memorandum 07-16 as “information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc.”
OMB defines IIF in OMB Memorandum 03-22 as “information in an IT system or online collection: (i) that directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or (ii) by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification. (These data elements may include a combination of gender, race, birth date, geographic indicator, and other descriptors).”⁵⁹
The following two distinctions exist between these terms:

• Indirect identification. The terms are distinct in how they address the issue of indirect identification. If information does not - by itself - identify an individual, it must be “intended by the agency” to identify an individual in conjunction with other data to meet the definition of IIF. The definition of PII does not address the agency’s intent and states that information can be PII even if the data is merely “linkable” to the individual, whether the agency intends to actually link it or not.
• Scope of policies. IIF is defined only in terms of identifying the IT systems for which a federal agency must complete a privacy impact assessment (PIA). PII is defined broadly to include personal information stored in any format, both electronic and paper-based.

7. How did the need for guidelines on protecting PII come about? Why is this important?

The protection of PII is 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. Organizations have always considered trust, confidence, and reputation as motivating factors in protecting PII. Recently, organizations have become more concerned about the risk of legal liability due to the enactment of many federal, state, and international privacy laws.

In the United States, Federal privacy laws are generally sector-based. For example, the Health Insurance Portability and Accountability Act of 1996 applies to the health care sector, and the Gramm-Leach-Bliley Act of 1999 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 the 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 H 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).

8. What is the Privacy Act?

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:

• Provide notice to individuals that explains:⁶¹
• The authority for the data collection
• The purpose of the data collection
• Routine uses for the data
• Effects, if any, of not providing the information
• Limit collection of data to the minimum necessary to accomplish the purpose of the agency
• Collect information directly from the person about whom the information pertains, if possible
• Maintain accuracy and completeness of the data
• Disclose the data to only those who need access for proper purposes, such as sharing for an identified routine use or to perform agency work
• Allow individuals to access data pertaining to them, request correction of wrong or incomplete data, and make an appeal for denials of requests for access and correction
• Maintain appropriate administrative, technical, and physical safeguards to ensure the security and confidentiality of the records.

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

Information contained within a Privacy Act System of Records usually will be considered PII. 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.

9. What is a Privacy Impact Assessment (PIA)? When do I need to conduct a PIA?

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. If used effectively, a PIA 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:

• Developing or procuring information technology that collects, maintains, or disseminates information that is in an identifiable form; or
• Initiating a new collection of information that -
• Will be collected, maintained, or disseminated using information technology; and
• Includes any information in an identifiable form permitting the physical or online contacting of a specific individual, if identical questions have been posed to, or identical reporting requirements imposed on, 10 or more persons, other than agencies, instrumentalities, or employees of the Federal Government.

 

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:

• Conversions - when paper-based records are to be converted to electronic systems
• De-Identified to Identifiable - when functions applied to an existing information collection change de-identified information into information in identifiable form
• Significant System Management Changes - when new uses of an existing IT system, including application of new technologies, significantly change how information in identifiable form is managed in the system
• Significant Merging - when agencies adopt or alter business processes so that government databases holding information in identifiable form are merged, centralized, matched with other databases, or otherwise significantly manipulated
• New Public Access - when user-authenticating technology (e.g., password, digital certificate, biometric) is newly applied to an electronic information system accessed by members of the public
• Commercial Sources - when agencies systematically incorporate into existing information systems databases of information in identifiable form purchased or obtained from commercial or public sources
• New Interagency Uses - when agencies work together on shared functions involving significant new uses or exchanges of information in identifiable form, such as the cross-cutting E-Government initiatives
• Internal Flow or Collection - when alteration of a business process results in significant new uses or disclosures of information or incorporation into the system of additional items of information in identifiable form
• Alteration in Character of Data - when new information in identifiable form added to a collection raises the risks to personal privacy (for example, the addition of health or financial information)

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

• What information is to be collected
• Why the information is being collected
• The intended use of the information
• With whom the information will be shared
• What opportunities individuals have to decline to provide information (i.e., where providing information is voluntary) or to consent to particular uses of the information (other than required or authorized uses), and how individuals can grant consent
• How the information will be secured
• Whether a system of records is being created under the Privacy Act, 5 U.S.C. 552a
• What choices the agency made regarding an IT system or collection of information as a result of performing the PIA.

10. What is the Paperwork Reduction Act?

The Paperwork Reduction Act (PRA)⁶³ was passed in 1995, and created a process for the review and approval of Federal government information collections from the public. The purpose of the Act is to minimize the burden 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. 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. A PIA is required for any electronic collection of information that includes PII and requires OMB clearance pursuant to the PRA.

11. What are the general risks to individuals and the organization if PII is misused?

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.

12. What should I consider when reviewing restrictions on collecting PII?

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; Gramm-Leach-Bliley Act (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.

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.

13. What are examples of PII?

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 records include financial transactions, medical history, criminal history, and employment history. Examples of individual data elements of PII include an individual’s name, social security number, passport number, driver’s license number, credit card number, vehicle registration or ID number, x-ray, patient ID number, and biometric image and template data (e.g., retina scans, voice signature, facial geometry).⁶⁵

14. What is different about protecting PII compared to any other data and how should PII be protected?

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. Also, there are several privacy-specific protection measures, 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 an overview of these requirements, which include, but are not limited to, notice, consent, access, correction, integrity, and enforcement. 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.

---

¹ Government Accountability Office (GAO) Report 08-343, Protecting Personally Identifiable Information, January 2008, http://www.gao.gov/new.items/d08343.pdf

² Congressional testimony as quoted by the New York Times, March 5, 1989. McGeorge Bundy was the U.S. National Security Advisor to Presidents Kennedy and Johnson (1961-1966). http://query.nytimes.com/gst/fullpage.html?res=950DE2D6123AF936A35750C0A96F948260

³ For the purposes of this document, confidentiality is defined as “preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.” 44 U.S.C. § 3542. http://uscode.house.gov/download/pls/44C35.txt.

⁴ For the purposes of this publication, both are referred to as “organizations”.

⁵ OMB Memorandum 07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information, http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf

⁶ The Census Bureau has a special obligation to protect based on provisions of Title 13 of the U.S. Code, and IRS has a special obligation to protect based on Title 26 of the U.S. Code. There are more agency-specific obligations to protect PII, and an organization’s legal counsel and privacy officer should be consulted.

⁷ This document provides some selected security control examples from NIST SP 800-53.

⁸ Disposal of PII should be conducted in accordance with the retention schedules approved by the National Archives and Records Administration (NARA).

⁹ OMB M-07-16 requires agencies to develop and implement breach notification policies.

¹⁰ Some organizations are structured differently and have different names for roles. These roles are examples, used for illustrative purposes.

¹¹ Even if an organization determines that information is not PII, the organization should still consider whether the information is sensitive or has organizational or individual risks associated with it, and determine the appropriate protections.

¹² OMB Memorandum M-07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information, http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf.

¹³ The terms “individual” and “individual’s identity” are used interchangeably throughout this document. For additional information about the term individual, see Appendix B.

¹⁴ For example PTA/IPA templates, see: http://www.usdoj.gov/opcl/initial-privacy-assessment.pdf or http://www.dod.mil/pubs/foi/privacy/DHS_PTA_Template.pdf.

¹⁵ As discussed in Section 3, the risk posed by these examples and the appropriate protections needed for each vary on a case- by-case basis.

¹⁶ Partial identifiers, such as the first few digits or the last few digits of SSNs, are also often considered PII because they are still nearly unique identifiers and are linked or linkable to a specific individual.

¹⁷ This document focuses on protecting the confidentiality of PII. Protecting the privacy of PII is a broader subject, and information about the Fair Information Practices is provided to increase reader awareness.

¹⁸ See: http://www.ftc.gov/reports/privacy3/fairinfo.shtm.

¹⁹ 44 U.S.C. § 3542, http://uscode.house.gov/download/pls/44C35.txt

²⁰ http://csrc.nist.gov/publications/PubsFIPS.html

²¹ http://csrc.nist.gov/publications/PubsSPs.html

²² This document pertains only to the confidentiality impact and does not address integrity or availability.

²³ Section 4.2 discusses how organizations can reduce the need to protect PII by removing PII from records.

²⁴ See Guide to U.S. Census Bureau Data Stewardship/Privacy Impact Assessments (DS/PIAs), http://www.census.gov/po/pia/Guide_to_PIAs.doc

²⁵ See Appendix H for additional resources.

²⁶ Personal information is defined in different ways by different laws, regulations, and other mandates. Many of these definitions are not interchangeable. Therefore, it is important to use each specific definition to determine if an obligation to protect exists for each type of personal information. See Appendix C for a listing of common definitions of personal information.

²⁷ The Census Bureau has a special obligation to protect based on provisions of Title 13 of the U.S. Code, and IRS has a special obligation to protect based on Title 26 of the U.S. Code. There are more agency-specific obligations to protect PII, and an organization’s legal counsel and privacy officer should be consulted.

²⁸ For additional information, see GLBA, 15 U.S.C. § 6801 et seq.

²⁹ CIPSEA is Title 5 of the E-Government Act of 2002, Pub.L. 107-347, 116 Stat. 2899, 44 U.S.C. § 101 et seq. CIPSEA covers all types of data collected for statistical purposes, not just PII. For additional information, see the OMB Implementation Guidance for CIPSEA, http://www.whitehouse.gov/omb/fedreg/2007/061507_cipsea_guidance.pdf.

³⁰ There are laws and OMB guidance that provide agency requirements for policy development. For example, OMB Memorandum 05-08 requires that a “senior agency official must…have a central policy-making role in the agency’s development and evaluation of legislative, regulatory and other policy proposals which implicate information privacy issues…” Additionally, the Privacy Act requires agencies to “establish rules of conduct for persons involved in the design, development, operation, or maintenance of any system of records, or in maintaining any record, and instruct each such person with respect to such rules and the requirements of…” the Privacy Act “including any other rules and procedures adopted…and the penalties for noncompliance.”

³¹ See NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems, http://csrc.nist.gov/publications/PubsSPs.html

³² Portions of this section were submitted as contributions to the ISO/IEC 29100 Framework for Privacy draft standard.

³³ Fair Information Practices are also referred to as privacy principles. See Appendix D for additional information.

³⁴ The frequency of reviews should be done in accordance with laws, regulations, mandates, and organizational policies that apply to the collection of PII.

³⁵ The Privacy Act requires that Federal agencies only maintain records relevant and necessary to their mission. Also, OMB directed Federal agencies to review their PII holdings annually and to reduce their holdings to the minimum necessary for proper performance of their missions. OMB Memorandum M-07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information, http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf

³⁶ The Federal Records Act, 44 U.S.C. § 3301, defines records as “[a]ll books, papers, maps, photographs, machine-readable materials, or other documentary materials, regardless of physical form or characteristics, made or received by an agency of the United States Government under Federal law or in connection with the transaction of public business and preserved or appropriate for preservation by that agency or its legitimate successor as evidence of the organization, functions, policies, decisions, procedures, operations, or other activities of the Government or because of the informational value of the data in them.” Agencies are required to create and maintain “adequate and proper documentation” of their organization, mission, functions, etc., and may not dispose of records without the approval of the Archivist of the United States. This approval is granted through the General Records Schedules (GRS) and agency specific records schedules.

³⁷ For the purpose of analysis, the definition for de-identified information used in this document is loosely based on the Standard for de-identified data defined in the HIPAA Privacy Rule, and it is generalized to apply to all PII. This definition differs from the HIPAA definition in that it is applied to all PII and does not specifically require the removal of all 18 data elements described by the HIPAA Privacy Rule. The HIPAA Privacy Rule recognizes two ways to de-identify data such that it is no longer considered to be protected health information (PHI). First, 18 specific fields can be removed, such as name, SSN, and phone number. Second, the anonymity of the data can be proven statistically. 45 CFR §164.514, http://www.hhs.gov/ocr/hipaa/finalreg.html

³⁸ Merriam Webster Dictionary Online, http://www.merriam-webster.com/dictionary/anonymous.

³⁹ Based on the Common Rule, which governs confidentiality requirements for research, 45 CFR 46.

⁴⁰ Both anonymizing and de-identifying should be conducted by someone with appropriate training. It may be helpful, as appropriate, to consult with a statistician to assess the level of risk with respect to possible unintended re-identification and improper disclosure. For additional information on statistical disclosure limitation techniques, see OMB’s Statistical Policy Working Paper #22, http://www.fcsm.gov/working-papers/spwp22.html. See also Census Bureau, Report on Confidentiality and Privacy 1790-2002, http://www.census.gov/prod/2003pubs/conmono2.pdf.

⁴¹ The Federal Committee on Statistical Methodology provides a checklist to assist in the assessment of risk for re-identification and improper disclosure. For additional information, see the Federal Committee on Statistical Methodology, Confidentiality and Data Access Committee’s Checklist on Disclosure Potential of Data Releases, http://www.fcsm.gov/committees/cdac/.

⁴² The retention of useful properties in anonymized data is dependent upon the statistical disclosure limitation technique applied.

⁴³ Anonymization is also commonly used by agencies to release data sets to the public for research purposes.

⁴⁴ For example, suppose that an organization has a database containing thousands of records on employees’ benefits. Instead of allowing a user to have full and direct access to the database, which could allow the user to save extracts of the database records to the user’s computer, removable media, or other locations, the organization could permit the user to access only the necessary records and record fields. A user could be restricted to accessing only general demographic information and not any information related to the employees’ identities. More information on restricting extracts from PII databases is available in Appendix E.

⁴⁵ Additional encryption guidelines and references can be found in FIPS 140-2: Security Requirements for Cryptographic Modules, http://csrc.nist.gov/publications/PubsFIPS.html.

⁴⁶ More information on authentication is available from NIST SP 800-63, Electronic Authentication Guideline.

⁴⁷ For more information on media sanitization, see NIST SP 800-88, Guidelines for Media Sanitization.

⁴⁸ NIST has several publications on this topic that are available from http://csrc.nist.gov/publications/PubsSPs.html.

⁴⁹ According to a 2007 Government Privacy Trust Survey conducted by the Ponemon Institute, a Federal department fell from being a top five most trusted agency in 2006 to just above the bottom five least trusted agencies after the highly publicized breach of millions of PII records in 2006. http://www.govexec.com/dailyfed/0207/022007tdpm1.htm

⁵⁰ U.S. Department of Commerce, Breach Notification Response Plan, September 28, 2007

⁵¹ In M-07-16, OMB required Federal agencies to report all known or suspected PII breaches to US-CERT within one hour.

⁵² For additional information about communications with external parties, such as the media, see NIST SP 800-61 Revision 1, Computer Security Incident Handling Guide, http://csrc.nist.gov/publications/PubsSPs.html.

⁵³ For Federal agencies, notification to US-CERT is always required.

⁵⁴ For additional information, see NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response, http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf.

⁵⁵ SP 800-61 Revision 1 is available at http://csrc.nist.gov/publications/PubsSPs.html.

⁵⁶ OMB M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002, http://www.whitehouse.gov/omb/memoranda/m03-22.html#1.

⁵⁷ See DHS Privacy Policy Regarding Collection, Use Retention, and Dissemination of Information on Non-U.S. Persons,
http://www.dhs.gov/xlibrary/assets/privacy/privacy_policyguide_2007-1.pdf.

⁵⁸ Immigration and Nationality Act, 8 U.S.C. 1202.

⁵⁹ OMB M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002

⁶⁰ 5 U.S.C. § 552a (a)(5).

⁶¹ The Privacy Act also requires publication of general notice in the Federal Register, which is called a System of Records Notice (SORN).

⁶² An agency may exempt itself from this requirement if publication of the PIA would raise national security concerns or reveal classified or sensitive information.

⁶³ PRA, 44 U.S.C. § 3501 et seq.

⁶⁴ For additional information, see: http://ocio.os.doc.gov/ITPolicyandPrograms/Information_Collection/dev01_003742.

⁶⁵ Organizations may want to consider how PII relating to deceased individuals should be handled, such as continuing to protect its confidentiality or properly destroying the information. Organizations may want to base their considerations on any obligations to protect, organizational policies, or by evaluation of organization-specific risk factors. With respect to organization-specific risk factors, there is a balancing act because PII relating to deceased individuals can both promote and prevent identity theft. For example, making available lists of deceased individuals can prevent some types of fraud, such as voter fraud. In contrast, PII of a deceased individual also could be used to open a credit card account or to set up a false cover for criminals. Organizations should consult with their legal counsel and privacy officer.

---

Оригинальный документ (pdf) | Перевод с помощью сервиса Google Translate