What is the purpose of a Privacy Impact Assessment (PIA)? 

A Privacy Impact Assessment (PIA) is an analysis of how personally identifiable information (PII) is collected, used, shared, and maintained. The purpose of a PIA is to demonstrate that system owners have consciously incorporated privacy protections within their systems for information supplied for by the public. 

PIAs are required by the E-Government Act of 2002, which was enacted by Congress in order to improve the management of Federal electronic government services and processes. Section 208 of the E-Government Act specifically requires PIAs to be created when a federal agency develops or procures new information technology that involves the collection, maintenance, or dissemination of information in identifiable form.

Further, because the E-Government Act also includes a provision requiring PIAs to be published publicly on agency websites, they allow CMS to communicate more clearly with the public about how we handle information, including how we address privacy concerns and safeguard information. Copies of completed PIAs are posted on the HHS website upon completion to offer transparency to the public.

PIAs must be completed in the following situations: 

• For all new systems that collect PII from 10 or more members of the general public, a PIA is required to be completed as part of the broader Authority to Operate (ATO) process.
• For every existing system that collects PII from 10 or more members of the general public, a PIA must be reviewed and re-approved once every three years. System/Business Owners and Information System Security Officers (ISSOs) must review and revise as necessary, and submit PIAs for re-approval no later than three years from the last HHS approval date. 
• For any existing system undergoing a major change, an updated PIA is required.
• An existing system that is going through the ATO process may need to update their PIA paperwork if it’s close to expiring; an ATO cannot be completed with an expired or incomplete PIA. 

If your FISMA system does not meet the requirements above, it may not require a traditional PIA. In these instances, there may be other Privacy compliance requirements for your system or application. For example, you may be required to complete a different type of assessment (such as a Privacy Threshold Analysis (PTA), Third Party Website Application (TPWA) Privacy Impact Assessment, or Internal Privacy Impact Assessment). 

PIA roles and responsibilities

HHS Chief Information Officer (CIO)/Senior Agency Official for Privacy (SAOP) 

At HHS, the Chief Information Officer (CIO) is designated as the Senior Agency Official for Privacy (SAOP) and provides the overall program structure for the completion of PIAs across all operating divisions. Responsibilities for the SAOP include, but are not limited to the following: 

• Develop a standard form for HHS PIAs
• Review PIAs from all operating divisions for adequacy, consistency, and compliance with federal and HHS requirements
• If the PIA meets HHS’s requirements, the PIA is signed by the SAOP, which finalizes the PIA for a period depending on the type of PIA
• Ensure all PIAs are published and made publicly available on HHS.gov

CMS Senior Official for Privacy (SOP)

At CMS, the Senior Official for Privacy (SOP) is the lead privacy official responsible for administering the agency PIA process and providing direction for the CMS privacy program. Unresolved privacy risks and other potential issues should be addressed before submission to the CMS SOP for final review. Responsibilities of the CMS SOP include, but are not limited to the following: 

• Establish a CMS specific framework for the development and completion of PIAs in accordance with federal and HHS requirements
• Review and approve all PIAs for completion and consistency prior to submission to the HHS SAOP in coordination with the CMS Final Approver
• Signing the PIA on behalf of CMS once the PIA satisfies federal and HHS requirements (The PIA will still require HHS’s final signature before publication to the HHS website)

CMS System Owner/Business Owner 

Information System Owners or Business Owners are individuals who are responsible for CMS FISMA systems or electronic information collections. System/Business Owners:

• Review, revise, and submit PIAs for approval for new systems or re-approval whenever a change to an IT system, a change in CMS practice, or another factor alters the privacy risks associated with the use of the IT system or electronic information collection. 
• Allocate proper resources to permit identification and remediation of privacy risks and weaknesses identified on PIAs. 
• Review, revise, and submit PIAs for re-approval three years from the last approval date, and as part of the authorization process as required. 
• Comply with all relevant Privacy Act requirements regarding any system of records, including, but not limited to, providing individuals with procedures for access and amendment of records.
• Ensure all artifacts are in place as needed such as a Computer Matching Agreement (CMA), Information Exchange Agreements (IEA), or any other agreement when sharing information. 

Depending on the structure of your specific team, some System/Business Owner responsibilities will be completed by the trained ISSO. Alternatively, some teams may utilize their System/Business Owner to complete ISSO tasks. Your team will decide what structure works best for your unique needs. 

CMS Privacy Advisor 

The Privacy Advisor has in-depth knowledge of privacy risks and can help your team meet the requirements for your PIA. The Privacy Advisor will complete the following tasks: 

• Review component PIAs for accuracy, consistency and compliance; coordinating with the Cyber Risk Advisor (CRA) to identify any outstanding privacy risks prior to submission to the CMS SOP. 
• Ensure answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook. 
• Check each PIA for other Privacy-related requirements (e.g. Privacy Act implications). 
• Review and edit each PIA for grammatical mistakes or incomplete responses. 
• Provide input and guidance as needed regarding any other privacy weaknesses as identified. 

CMS Cyber Risk Advisor (CRA) 

The CRA is responsible for coordinating the drafting and review process of the PIA with the CMS office or center in which they are representing. The CRA will: 

• Communicate with System/Business Owners through the authorization process, and ensure that the PIA is included in the authorization package.
• Review PIAs submitted by the ISSO or System Owner for potential security and privacy risk, this can include:
  • Checking that information in the PIA matches other artifacts in the ATO package as needed, including checking for grammatical mistakes or incomplete responses. 
  • Ensuring the answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook. 
• Coordinate with the Privacy Advisor to identify any potential privacy risks during the review of the PIA. 
• Review PIAs sent back from the SOP and/or HHS and coordinate with the ISSO and Privacy Advisor to resolve the outstanding comments as needed. 
• Coordinate with the Privacy Advisor to submit completed PIAs for approval to the CMS SOP. 

CMS Information System Security Officer (ISSO) 

The ISSO provides oversight and develops documentation to ensure the completion of the Security Assessment and Authorization (SA&A) process for their information systems. The ISSO typically performs this function on behalf of the System/Business Owner for the FISMA system. The PIA is included as one of the artifacts in the Security Assessment and Authorization package. The ISSO will: 

• Draft a new PIA or modify a PIA in coordination with the System Owner and CRA to address major changes or PIA requirements.
• Contact the CRA to obtain either HHS or CMS PIA guidance when required. 
• Engage with the System/Business Owner, CRA, Privacy Advisor, and CMS leadership to ensure all comments and suggestions are included in the PIA
• Assist in identifying and remediating potential privacy risks and notify System/Business Owners of PIA requirements;  
• Inform the CRA when a planned, new or existing system will require a PIA

Steps for completing your PIA

The Department of Health and Human Services (HHS) issues the master guidance for completing PIAs. ISPG has taken the guidance provided by HHS and translated it into a questionnaire found on CFACTS. ISSOs can log in to CFACTS to complete the questionnaire with guidance from the System/Business Owner and the assigned Cyber Risk Advisor (CRA). A step-by-step guide to answering the questions required to complete the PIA can be found within the PIA & PTA Writer’s Handbook, which is written by HHS and can be found as a resource on the front page of each question in CFACTS. If you would like a copy of the PIA & PTA Writers Handbook, please contact the Privacy Office. The procedures below give a summary review of the actions necessary to complete a new PIA or modify an existing PIA.

Step 1: PIA initial draft

Primary Responsibility: SO/BO, ISSO, Cyber Risk Advisor

Following any of the scenarios or major changes that would require the completion of a PIA, the System/Business Owner works with the ISSO to draft a new or revised PIA in CFACTS. Upon completion of the new or revised PIA, the System/Business Owner or ISSO will contact the CRA for review. In CFACTS, the queue for the System/Business owner or ISSO is “ISSO Submitter” for the PIA.

Step 2: PIA review / revision

Primary Responsibility: CRA, Privacy Advisor

The CRA reviews the PIA in collaboration with the Privacy Advisor and coordinates recommended changes with the system/business owner or ISSO. Any identified privacy risks or compliance issues should be resolved before submission to the SOP for approval. If the SOP or SAOP recommends changes, the review process will return to this step as needed until the PIA is approved and finalized by the Senior Agency Official for Privacy (SAOP). 

Step 3: PIA approval

Primary Responsibility: CMS Senior Official for Privacy (SOP), Final Approver

The SOP or designated Final Approver will review the PIA and recommend approval to HHS if no changes are recommended.

Step 4: PIA signing

Primary Responsibility: Senior Agency Official for Privacy (SAOP)

The SAOP will designate staff to review all PIAs before approval for signature. If no changes are recommended, the SOP and SAOP will digitally sign the PIA. Once signed by the SOP and SAOP, the PIA is approved and complete for a length of time as discussed above.

Step 5: PIA posting

Primary Responsibility: Senior Agency Official for Privacy (SAOP)

The SAOP will send the completed PIA to HHS. HHS will submit the final PIA for publication to the HHS PIA internet site at https://www.hhs.gov/pia.

Tips for completing your PIA

Before starting to fill out your PIA, obtain and review any available program and system documentation. This may include:

• Websites that explain the service or business process supported by the system;
• Information Collection Requests (ICRs) if the system collects information from the public and is subject to the Paperwork Reduction Act (PRA); if unsure, please reach out to the PRA office. 
• Privacy Act Statements (PASs) and System of Records Notices (SORNs) if records in the system are subject to the Privacy Act;
• Agency IT Portfolio Summaries (formerly called Exhibit 53s) or any Major IT Investment Business Cases (formerly called Exhibit 300s);
• Enterprise Program Lifecycle Artifacts such as a System Security and Privacy Plan (SSPP); and
• Any handbooks or other guidance on how to use the system.

It may be possible to reuse language from these documents to respond to questions. However, make sure you review all copied text to verify that it is specific to the system being reviewed, is complete, and makes sense absent the rest of the document. Text copied from marketing materials and system planning documents may discuss functions that were never purchased or implemented. Text copied from a SORN or budget document may describe more than one system.

The purpose of a PIA is to provide the general public with information about how CMS systems collect and share user data. The general public is the audience for PIAs, so it’s essential to keep your end users in mind when drafting your PIA. 

• Answer each question briefly; text fields have a limited capacity when translated to the final documentation in CFACTS
• Write in a way that is easily understood by the general public; avoid using overly technical language, and clearly define technical terms and references if needed to describe a system.
• Define each acronym the first time it is used; use the acronym alone in all subsequent references.
• Do not include sensitive or confidential system information or information that could allow a potential threat source to gain unauthorized access into the system (e.g., do not provide detailed information on technical security controls)
• Provide information about authentication credentials. Reviewers need to know if the system is accessed using system-specific login information such as a username and password or if the system uses only PIV access and single sign-on authentication. The login method determines how user credentials are stored outside the system boundary. Please include a statement indicating whether login information is stored in the system.
• Make it clear who the “users” are for your system. In some cases, it may be confusing whether “users” refers to individuals creating records about themselves or whether “users” are CMS staff members receiving and acting on this information. Please make this distinction clear the first time the term “users” is used. If contractors are listed as users, please cite if contractors are “direct” or “indirect”. 

Guidance for specific PIA questions

Completing a Privacy Impact Assessment (PIA) can be a challenge. It’s essential to provide all the relevant information while ensuring it is correct and up to date. The following guidance comes from the Privacy Office, as well as a number of ISSOs and System/Business Owners who have experience completing successful PIAs in CFACTS. 

• For PIA question 6b, make sure the ISSO information is correct and up to date.
• When answering question 10, consider all changes that have occurred since the PIA was last finalized, as well as the changes that will occur when the PIA is finalized. All changes, whether or not they pose a new privacy risk, should be documented. Examples of changes include changing the physical location of a server or adding additional collection of new PII elements.
• For PIA question 11, you should include what HHS functions are supported by the system and how the system completes those functions. Your response should be concise and specific, and should not contain jargon or overly technical terms so that a reader with no prior knowledge of the system will understand the response. Don’t forget to spell out all acronyms on first usage. 
• For PIA question 12, list and describe all types of information collected by the system regardless of whether that information is considered PII. Make sure to include how long information is stored in the system. If the system holds system-specific access credentials, e.g., username, password, please describe those components in the response to this question. Specify whether the username and/or password are created by the individual, generated by the system, provided by a system administrator, or established through some other process.  Reminder: Any types of PII listed in this response also need to be listed in PIA question 15. 
• For PIA question 12, describe why the information listed in the question is collected. The response to this question should consider all information, whether or not it is PII. The response to this question should also specify what information is collected about each category of individual and should document and discuss if records are retrieved by PII elements.
• For PIA question13, include a brief description of the method of record retrieval, if you answered “Yes'' to PIA question 22 regarding System of Record Notification (SORN). Note the PII used and categories of individuals to whom the PII relates. 
  • An example is: The Physical Security System (PSS) regularly uses PII to retrieve system records including using the last name, employee ID number, and/or work phone number of CMS employees, contractors, and members of the public authorized to access the main campus and satellite offices.
• PIA question 14 is calculated by the system. Reminder: If the response to this question is No, PIA questions 15 through 38 should no longer appear on the form. 
• If PIA question 15 is shown, check all the boxes that apply. If the information collected by the system is not described by any of the items in the list, there is a text field under ‘Other’ where you can list additional information. Your response should include all types of PII regardless of type sensitivity, or whether it is from employees or the public. Reminder: PII elements need to be accounted for in both PIA question 12 and PIA question 15.
• PIA question 20 should describe all the ways Social Security Numbers (SSNS) are used in the system (if applicable). You’ll need to share when, where, and why an SSN is disclosed or shared; and why the SSN is used rather than another identifier. 
  • NOTE: Employer Identification Number (EIN) also known as Federal Employer Identification Number (FEIN) or Tax Identification Number (TIN) or Federal Tax Identification Number (FTIN).  Individuals may choose to use their SSN as their EIN or FTIN. Typically, this would be sole proprietors or other small business owners who use SSN as EIN for tax purposes. EIN often appears in the format XX-XXXXXXX and may not stand out as a SSN. Any time that Social Security Numbers are involved, examine whether the collection and/or use of the SSN can be eliminated. 

Reminder: If the response to this question states that SSNs are collected, SSNs should also be listed in the response to PIA question 15.

• PIA question 21 asks for the legal authorities governing information collection. Every system with PII must have an authority to collect this information. This will be a statute or Executive Order that either (a) permits or requires collection of the PII, or (b) permits or requires the underlying activity, for which it is necessary to collect PII.
• PIA questions 22 and 22a are relevant to System of Record Notifications (SORNs). If the
• system uses PII to retrieve records, it may need to be covered by a SORN. Any system that has already received Privacy Office signatures should already reference a SORN. If not, you may need to seek guidance from ISPG or DSPPG to determine whether a SORN is required and in identifying an existing SORN that might apply. Please also review your response to PIA question 13 to ensure that it matches with your response here in question 22. 
• Each system has unique functions and answers to questions will be different for different systems. Question 23 determines whether your system needs an Information Collection Approval number from the White House Office of Management and Budget (OMB). In some cases, when you answer question 23, question 23a will appear. It asks about an OMB Information Collection Approval number. Under the Paperwork Reduction Act (PRA), the System/Business Owner or ISSO may need to obtain an information collection approval number from the OMB. Use the information in the CMS guidance and HHS PIA Writers’ Handbook regarding this question to contact subject matter experts as needed.
• For PIA question 27, please state that any system that utilizes information obtained from the Enterprise Portal (EIDM) must provide individuals the option to opt-out of information sharing. And similar to PIA question 25, if EIDM has its own PIA for CMS please add this statement.
• For PIA question 29, Identify System Acronym
• For PIA question 37, NARA Disposition Schedule ID, and the retention period described by the schedule, should be included
• PIA question 37 asks about the system retention schedule. Every system (whether it contains PII or not) should have been made subject to an information retention schedule. Check with the Records Officer to identify the appropriate retention schedule.