Identity Management
Privacy Impact Assessment (PIA) published by CMS as an Operating Division of the U.S. Department of Health and Human Services
Date signed: 7/22/2022
OPDIV: | CMS |
|---|---|
PIA Unique Identifier: | P-5127102-673341 |
Name: | Identity Management |
The subject of this PIA is which of the following? | Major Application |
Identify the Enterprise Performance Lifecycle Phase of the system. | Operate |
Is this a FISMA-Reportable system? | Yes |
Does the system include a Website or online application available to and for the use of the general public? | Yes |
Identify the operator: | Agency |
Is this a new or existing system? | Existing |
Does the system have Security Authorization (SA)? | Yes |
Date of Security Authorization | 2/9/2023 |
Indicate the following reason(s) for updating this PIA. Choose from the following options. | Other - The current PIA expired and added PII field Mailing address |
Describe in further detail any changes to the system that have occurred since the last PIA. | The changes performed on the system since the last PIA approval, includes IDM account's Annual Role Certification, account review, account inactivity and cleanup process. |
Describe the purpose of the system | In support of the American Recovery and Reinvestment Act (ARRA), the Health Information Technology for Economic and Clinical Health Act (HITECH), and the Patient Protection and Affordable Care Act of 2010, also known as Affordable Care Act (ACA), Centers for Medicare & Medicaid Services (CMS) has implemented an Identity Management (IDM) system. Identity Management (IDM) is an Identity and Access Management (IAM) system that provides application program interface (API) and user interface services as a means for users needing access to CMS applications to self-identify, apply for and receive credentials in the form of a single-factor authentication, User Identifier (UserID) and Password and/or Multi-Factor Authentication (MFA). IDM manages the lifecycle of user IDs, passwords, and the supporting data collected from the users from issuance through deprovisioning and archival. IDM services are grouped into four main areas:
|
Describe the type of information the system will collect, maintain (store), or share. (Subsequent questions will identify if this information is PII and ask about the specific data elements) | IDM collects, maintains and stores the following information on external and internal CMS system users: First Name, Last Name, Date of Birth, E-mail Address, Mailing address, Phone Number, Social Security Number, User Identifier (User ID) and Password and Organization Name. The Social Security Number is used to check for registrant uniqueness within the system. The First Name, Last Name, Date of Birth, Phone Number, and Organization Name are used by the approver to approve the user’s request for access. The User Identifier (User ID) and Password are used to grant access to applications, users have been authorized to access. |
Provide an overview of the system and describe the information it will collect, maintain (store), or share, either permanently or temporarily. | Identity Management (IDM) is an Identity and Access Management (IAM) system that provides application program interface (API) and user interface services as a means for users needing access to CMS applications to self-identify, apply for and receive credentials in the form of a single-factor authentication, User Identifier (UserID) and Password and/or Multi-Factor Authentication (MFA). IDM manages the lifecycle of user IDs, passwords, and the supporting data collected from the users from issuance through deprovisioning and archival. IDM collects, stores and maintains the following information: First Name, Last Name, Date of Birth, E-mail Address, Mailing address, Phone Number, Social Security Number, User Identifier (User ID) and Password and Organization Name. The Social Security Number is used to check for registrant uniqueness within the system. The First Name, Last Name, Date of Birth, Phone Number, and Organization Name are used by the approver to approve the user’s request for access. The User Identifier (User ID) and Password are used to grant access to application users who have been authorized to access. IDM tier 1 and tier two helpdesk (HD) users and approvers of the tier one /vertical applications will use the end-user's PII to retrieve system records. This retrieval is normally done by leveraging the user's username, Date of birth and/or last four of SSN in the search section of the HD user interface. |
Does the system collect, maintain, use or share PII? | Yes |
Indicate the type of PII that the system will collect or maintain. |
|
Indicate the categories of individuals about whom PII is collected, maintained or shared. |
|
How many individuals' PII in the system? | 100,000-999,999 |
For what primary purpose is the PII used? | The primary purpose of the system is to collect and maintain individually identifiable information to assign, control, track, and report authorized access to and use of CMS’ computerized information and resources, for those individuals who apply for and are granted access across multiple CMS systems and business contexts. Information in this system is also used to: (1) Support regulatory and policy functions performed within the Agency or by a direct contractor, consultant, or CMS grantee; and (2) Support litigation involving the Agency related to this system. The Social Security Number is used to check for registrant uniqueness within the system. The First Name, Last Name, Date of Birth, and Phone Number are used by the approver to approve the user’s request for access. |
Describe the secondary uses for which the PII will be used (e.g. testing, training or research) | None |
Describe the function of the SSN. | The main purpose of the Social Security Number (SSN) is for Remote Identity Proofing (RIDP). Level of Assurance (LOA) 3 users will provide SSN for RIDP. For LOA 2 Users, SSN is optional. The Social Security Number is also used to check for registrant uniqueness within the system. |
Cite the legal authority to use the SSN. | Executive Order 9397, the Debt Collection Improvement Act (PUBLIC LAW 104–134—APR. 26, 1996), 31 United States Code (U.S.C.) § 7701(c)(1), and 5 U.S.C. 552a(b)(1) |
Identify legal authorities governing information use and disclosure specific to the system and program. | U.S.C. § 7701(c)(1), Appellate procedures Executive Order 9397, the Debt Collection Improvement Act (PUBLIC LAW 104–134—APR. 26, 1996), 31 United States Code (U.S.C.) § 7701(c)(1), and 5 U.S.C. 552a(b)(1) |
Are records on the system retrieved by one or more PII data elements? | Yes |
Identify the number and title of the Privacy Act System of Records (SORN) that is being used to cover the system or identify if a SORN is being developed. | Published: SORN 09-70-0538, Individuals Authorized Access to CMS Computer Services |
Identify the sources of PII in the system: Directly from an individual about whom the information pertains |
|
Identify the sources of PII in the system: Government Sources | Within the OPDIV |
Identify the sources of PII in the system: Non-Government Sources |
|
Identify the OMB information collection approval number and expiration date | OMB No.0938-1236 | Expiration Date: 03/31/2021 | Per Office of Strategic Operations and Regulatory Affairs (OSORA) at this time, collection CMS-10524 is at the top of OMBs list regarding oldest packages and should be reviewed soon. |
Is the PII shared with other organizations? | Yes |
Identify with whom the PII is shared or disclosed and for what purpose. | Private Sector: Experian Information Solutions, Inc. provides Remote Identity Proofing (RIDP) services. PII is sent to Experian over a secure channel using Federal Information Processing Standards (FIPS) 140-2 compliant encryption. Experian enables IDM to prove the identity of users. |
Describe any agreements in place that authorizes the information sharing or disclosure (e.g. Computer Matching Agreement, Memorandum of Understanding (MOU), or Information Sharing Agreement (ISA)). | Information Sharing Agreement (ISA) with Experian, reviewed in May 2020: Experian provides Remote Identity Proofing (RIDP) web services for IDM to remotely identity proof its users. |
Describe the procedures for accounting for disclosures | The disclosure of any PII is documented via the ISA with Experian, as well as, the CMS Incident Management process. A Service Now ticket is created to record the incident and all relevant information to the incident (i.e. What was disclosed, when, how, by whom). An incident investigation will be initiated, and the results documented in the Service Now ticket and a report provided to the data owner for all involved systems. Appropriate remediation actions will be taken based on nature of the incident. |
Describe the process in place to notify individuals that their personal information will be collected. If no prior notice is given, explain the reason. | There is a Privacy Act Statement that users must accept during initial registration and again on a yearly basis. The privacy act statement is included in the Terms and Conditions that the user accepts. The Privacy Act Statement describes how IDM will use the information the user provides. It further describes that the collection of Personal Identifiable Information (PII) is necessary for the identity proofing services being requested which are regulated by the Fair Credit Reporting Act and that a user's explicit consent is required to use these services. Users must accept the Privacy Act Statement included in the Terms and Conditions on initial registration and at login. . |
Is the submission of the PII by individuals voluntary or mandatory? | Voluntary |
Describe the method for individuals to opt-out of the collection or use of their PII. If there is no option to object to the information collection, provide a reason. | Users must accept a Privacy Act Statement included in the Terms and Conditions on initial registration and at login. Users may opt out of providing their information, however, if a user chooses not to accept the terms and Conditions during the initial registration then a user account cannot be created for the user. Therefore, the user will not be able to access CMS applications that require login credentials. |
Describe the process to notify and obtain consent from the individuals whose PII is in the system when major changes occur to the system (e.g., disclosure and/or data uses have changes since the notice at the time of original collection). Alternatively, describe why they cannot be notified or have their consent obtained. | Users must accept a Privacy Act Statement which provides users with the uses of data, this is included in the Terms and Conditions on initial registration and at login. A warning banner is also displayed that describes that the system is a government operated system, and that individuals can opt out of usage of IDM at any time. |
Describe the process in place to resolve an individual's concerns when they believe their PII has been inappropriately obtained, used, or disclosed, or that the PII is inaccurate. If no process exists, explain why not. | Any concerns of inappropriate gathering or use of an individual's PII should be directed to the IDM Help Desk or sent in writing to Medicare following the complaint process outlined in Medicare’s Notice of Privacy Practices. A Service Now ticket will be created to record the incident and all relevant information to the incident (i.e. What was disclosed, when, how, by whom). An incident investigation will be initiated, and the results documented in the Service Now ticket and a report provided to the data owner for all involved systems. Appropriate remediation actions will be taken based on nature of the incident. |
Describe the process in place for periodic reviews of PII contained in the system to ensure the data's integrity, availability, accuracy and relevancy. If no processes are in place, explain why not. | Each application supported by IDM is responsible for verifying the accuracy of PII collected on their behalf. IDM supports at least sixty CMS applications. PII data is protected in transit and storage using FIPS 140-2 approved encryption. An annual Adaptive Control Testing (ACT) will be conducted to ensure compliance with the CMS Acceptable Risk Safeguards. IDM will use role-based access controls to ensure that administrators and users are granted access on a ‘least privilege’ basis commensurate with their assigned duties (only those with the "need" to access the system are granted access for their assigned tasks/duties). IDM system administrators and contractors will ensure system availability and the PII that is within IDM. |
Identify who will have access to the PII in the system and the reason why they require access. |
|
Describe the procedures in place to determine which system users (administrators, developers, contractors, etc.) may access PII. | IDM uses role-based access controls to ensure that administrators, and users are granted access on a ‘least privilege’ basis that is commensurate with their assigned duties (only those with the "need" to access the system are granted access for their assigned tasks/duties). Individuals requesting access to a CMS application through IDM must submit a request indicating the level of access. The request is reviewed and approved by the business owner before access is granted to the application. |
Describe the methods in place to allow those with access to PII to only access the minimum amount of information necessary to perform their job. | IDM uses the principle of least privilege as well as role-based access control to ensure system administrators and users are granted access on a "need-to-know" and a "need-to-access" basis that commensurate with their assigned duties. Individuals requesting access to a CMS application through IDM, must submit a request indicating the level of access. The request is reviewed and approved by the business owner before access is granted to the application. |
Identifying training and awareness provided to personnel (system owners, managers, operators, contractors and/or program managers) using the system to make them aware of their responsibilities for protecting the information being collected and maintained. | All IDM users are required to take the CMS Information Security and Privacy training on an annual basis, or whenever changes to the training module are made. This training includes details on the handling of PII. |
Describe training system users receive (above and beyond general security and privacy awareness training) | System administrators and users are required to complete role-based training and meet continuing education requirements commensurate with their role. Other training avenues such as conferences, seminars and classroom training provided by CMS/HHS is available apart from the regular annual training. |
Do contracts include Federal Acquisition Regulation and other appropriate clauses ensuring adherence to privacy provisions and practices? | Yes |
Describe the process and guidelines in place with regard to the retention and destruction of PII. Cite specific records retention schedules. | National Archives and Records Administration (NARA), General Records Schedule (GRS) 20 states that EIDM will destroy/delete all records that are 7 years 6 months, 10 years 6 months, or 20 years 6 months old, based on the maximum level of operation of the Certification Authority, or when no longer needed for business, whichever is later. GRS 24 states that IDM will delete/destroy all records when the agency determines they are no longer needed for administrative, legal, audit or other operational purposes. The following are all NARA approved records schedules for IDM: 1. Master Files a. Registration - username/password and challenge question/answers, allows users to prove their identify by associating federate credentials as well as use these credentials for subsequent authentication DISPOSITION: Destroy/delete when 7 years 6 months, 10 years 6 months, or 20 years 6 months old, based on the maximum level of operation of the Certification Authority, or when no longer needed for business, whichever is later. (Disposition Authority, GRS 24, item 13a1) b. Authorization - manages applications as well as entitlements within applications as requested items to end users; integration of CMS applications into IDM; connects with application stores specific to Federal Exchange using the database connector.
|
Describe, briefly but with specificity, how the PII will be secured in the system using administrative, technical, and physical controls. | IDM uses the principle of least privilege as well as a role based access control to ensure system administrators, and users are granted access on a "need-to-know" and "need-to-access" basis that commensurate with their assigned duties. Individuals requesting access to a CMS application through IDM must submit a request indicating the level of access. The request is reviewed and approved by the business owner before access is granted to the application. IDM is located in General Dynamics Information Technology (GDIT) Amazon Web Services (AWS) Virtual data center which provides premier physical control protections. Physical controls are in place such as security guards to ensure that access to the buildings is granted to authorize individuals. Identification of personnel is checked at the data center. IDM is built using industry best practices and independently reviewed against Federal Information Security Management Act (FISMA) and National Institute of Science and Technology (NIST) Security and Privacy controls to ensure technical, operational, and management controls are properly applied.
|
Identify the publicly-available URL: | https://portal.cms.gov/ |
Does the website have a posted privacy notice? | Yes |
Is the privacy policy available in a machine-readable format? | Yes |
Does the website use web measurement and customization technology? | Yes |
Select the type of website measurement and customization technologies is in use and if is used to collect PII. (Select all that apply) |
|
Does the website have any information or pages directed at children under the age of thirteen? | No |
Does the website contain links to non-federal government website external to HHS? | Yes |
Is a disclaimer notice provided to users that follow external links to websites not owned or operated by HHS? | Yes |