DRAFT_CMS_Privacy_Handbook_v5_10122018€¦ · Web viewtypes of information processed, privacy and...

Centers for Medicare & Medicaid ServicesInformation Security and Privacy Group

Privacy Handbook

Version 1.0

December 31, 2018

Privacy Handbook December 31, 2018

Centers for Medicare & Medicaid Services Summary of Changes

Summary of ChangesVersion Number

Date Revised Section

Author/Owner Name

Description of Change

1.0 2018.12.31 All ISPG Initial Release

Effective Date/ApprovalThis document becomes effective on the date the CMS Chief Information Security Officer (CISO) and Senior Official for Privacy (SOP) signs it and remains in effect until it is rescinded, modified or superseded.

Signature: /s/

Date of Annual Review: 12/31/2018

Emery CsulakCMS Chief Information Security Officer and Senior Official for Privacy

Owner’s Review CertificationThis document must be reviewed in accordance with the established review schedule located on the CMS website .

Signature: /s/

Date of Annual Review: 12/31/2018

Michael PagelsDirector, Division of Security and Privacy Policy and Governance (DSPPG)

Privacy Handbook iiVersion 1.0 December 31, 2018

http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/index.html

Centers for Medicare & Medicaid Services Executive Summary

Executive SummaryThe Privacy Handbook is guidance intended for CMS Business Owners and Project Managers who need to collect, use, and disclose personally identifiable information (PII), including protected health information (PHI). The Information Security and Privacy Group (ISPG) supports the legal responsibilities of the Center for Medicare & Medicaid Services (CMS) to protect PII. ISPG’s responsibilities include developing policy and guidance related to safeguarding PII/PHI when it is collected, used, and shared with outside entities. ISPG assists Business Owners and other CMS staff with addressing legal and regulatory requirements imposed by such authorities as the e-Government Act of 2002, the Privacy Act of 1974, the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule, and many others. These safeguards ensure that PII is shared with third parties only for authorized purposes, PII/PHI is adequately safeguarded during transmission and while in the possession of third parties, PII/PHI is used only for the purposes for which the recipient has been authorized, and that only the minimum necessary amount of PII/PHI is disclosed to achieve the purpose of the disclosure. The two most common approaches CMS uses to ensure third parties are aware of their responsibilities are (1) executing agreements and (2) drafting and posting notices. CMS executes agreements with parties to whom it will disclose PII/PHI to ensure all parties will safeguard it appropriately. CMS provides notices to the public to maintain transparency concerning privacy and security safeguards.

Privacy Handbook iiiVersion 1.0 December 31, 2018

Centers for Medicare & Medicaid Services Table of Contents

Table of Contents1. Introduction..................................................................................................................2

1.1. Purpose.............................................................................................................................21.2. Scope................................................................................................................................21.3. Audience...........................................................................................................................21.4. Roadmap...........................................................................................................................2

2. How to Use the Privacy Handbook.............................................................................22.1. Privacy Trigger Questions................................................................................................22.2. One-Pagers.......................................................................................................................22.3. Standard Operating Procedures........................................................................................22.4. Templates.........................................................................................................................2

3. Roles and Responsibilities............................................................................................23.1. Program Executive...........................................................................................................23.2. Portfolio Lead...................................................................................................................23.3. Information System Owner..............................................................................................23.4. Data Guardian..................................................................................................................23.5. Business Owner................................................................................................................23.6. Project Manager...............................................................................................................23.7. Privacy Advisor................................................................................................................23.8. Information System Security Officer...............................................................................23.9. Contracting Officer and Contracting Officer's Representative........................................2

4. Trigger Questions.........................................................................................................2

5. System of Records Notice.............................................................................................25.1. SORN One-Pager.............................................................................................................25.2. SORN Standard Operating Procedure..............................................................................2

6. Computer Matching Agreement.................................................................................26.1. CMA One-Pager...............................................................................................................26.2. CMA Standard Operating Procedure...............................................................................26.3. CMA Federal Register Publication Template..................................................................26.4. CMA Letter to House Committee Template....................................................................26.5. CMA Letter to Senate Template......................................................................................26.6. CMA Letter to OMB Template........................................................................................26.7. CMA Narrative Statement Template................................................................................2

7. Information Exchange Agreement..............................................................................27.1. IEA Review One-Pager....................................................................................................27.2. IEA Standard Operating Procedure..................................................................................2

Privacy Handbook ivVersion 1.0 December 31, 2018


8. Interconnection Security Agreement..........................................................................28.1. ISA One-Pager.................................................................................................................28.2. ISA Standard Operating Procedure..................................................................................2

9. Third-Party Websites and Applications.....................................................................29.1. TPWA One-Pager............................................................................................................29.2. TPWA Standard Operating Procedure.............................................................................2

10. Other Agreements........................................................................................................210.1. Data Use Agreement......................................................................................................210.2. Inter-Agency Agreement...............................................................................................210.3. Memorandum of Understanding....................................................................................210.4. Memorandum of Agreement..........................................................................................210.5. Other Agreements..........................................................................................................2

Appendix A Acronyms...............................................................................................A-2

Appendix B Glossary.................................................................................................B-2

Appendix C Applicable Laws and Guidance...........................................................C-2

Appendix D SORN Template....................................................................................D-2

Appendix E CMA Federal Register Publication Template....................................E-2

Appendix F CMA Letter to House Committee Template......................................F-2

Appendix G CMA Letter to Senate Template.........................................................G-2

Appendix H CMA Letter to OMB Template...........................................................H-2

Appendix I CMA Narrative Statement Template...................................................I-2

Appendix J IEA Template.........................................................................................J-2

Appendix K ISA Template........................................................................................K-2

Appendix L TPWA Template...................................................................................L-2

Appendix M Points of Contact..................................................................................M-2

Privacy Handbook vVersion 1.0 December 31, 2018


List of FiguresFigure 1. SORN One-Pager.............................................................................................................2

Figure 2.CMA One-Pager................................................................................................................2

Figure 3. IEA One-Pager.................................................................................................................2

Figure 4. ISA One-Pager.................................................................................................................2

Figure 5. TPWA One-Pager............................................................................................................2

List of TablesTable 1. Trigger Questions to Determine Required Documentation...............................................2

Table 2. SORN Review Standard Operating Procedure..................................................................2

Table 3. CMA Standard Operating Procedure.................................................................................2

Table 4. IEA Standard Operating Procedure...................................................................................2

Table 5. ISA Standard Operating Procedure...................................................................................2

Table 6. TPWA Standard Operating Procedure..............................................................................2

Privacy Handbook viVersion 1.0 December 31, 2018

Centers for Medicare & Medicaid Services Introduction

1. Introduction

1.1. PurposeThe Privacy Handbook identifies and explains the processes and procedures Centers for Medicare & Medicaid Services (CMS) stakeholders must use when collecting, using, or disclosing personally identifiable information (PII) and protected health information (PHI). These processes include developing public notices and executing agreements between CMS and data recipients. The required processes and procedures may vary based on the circumstances of the collection, use, and disclosure of PII/PHI.

The Handbook is intended to be an easy-to-use source for answers to frequently asked questions about these processes and procedures. The CMS Division of Security, Privacy Policy, and Governance (DSPPG) within the Information Security and Privacy Group (ISPG) updates this document periodically to add material that addresses additional concerns or questions. By serving as a valuable and frequently consulted resource, the Privacy Handbook strengthens CMS’s ability to protect individuals’ PII/PHI and to support its mission, as well as to ensure transparency and trust with CMS beneficiaries and the public.

1.2. ScopeThe Privacy Handbook focuses on the necessary processes and procedures when the following types of notices and agreements are required:

Systems of Records Notices (SORN) Computer Matching Agreements (CMA) Interconnection Security Agreements (ISA) Information Exchange Agreements (IEA) Third-Party Websites and Applications Privacy Impact Assessments (TPWA)

The processes and procedures for creating these notices and agreements may depend on the recipient of the PII/PHI that CMS discloses. Recipients may include:

Department of Health and Human Services (HHS) Staff Divisions (StaffDiv) and Operating Divisions (OpDiv)

Other federal agencies State agencies Commercial entities Individuals or institutions requesting information under laws promoting government

transparency and accountability

The Privacy Handbook also addresses processes and procedures depending on the activity on the purpose of the disclosure such as:

Complying with a statute requiring the coordination of two or more agencies Coordinating activity among agencies and private sector business partners Responding to requests from individuals to view records about themselves

Centers for Medicare & Medicaid Services System of Records Notice

Responding to requests from members of the public authorized to receive the requested information

Enlisting the assistance of a contractor or other business partner to conduct an activity necessary to meet the mission of CMS

CMS is permitted or required to disclose PII/PHI to other external parties or agencies, such as to Congress, the Census Bureau, law enforcement or counterterrorism authorities, courts of appropriate jurisdiction, and others. These types of disclosures are not in scope of the current version of this Handbook. This version instead focuses on disclosures that require certain types of agreements and notices. It also provides pointers to additional information about appropriate collection, uses, and disclosures of PII/PHI.

1.3. AudienceISPG developed the Privacy Handbook for those responsible for processes or information technology (IT) systems that collect, use, or disclose PII/PHI, including Business Owners, Project Managers, and others. In this Handbook, these potential users of the Handbook are sometimes referred to as “users.” These individuals are responsible for developing required agreements and notices prior to disclosing PII/PHI. The Privacy Handbook is also useful for parties seeking to understand when, why, and how to create these documents, who may include Information System Owners (ISOs), individuals with roles in the IT system eXpedited Lifecycle (XLC), external requestors and recipients of PII/PHI, and senior management staff.

To benefit to the greatest degree possible from this Handbook, users should have some familiarity with CMS, its business practices, basic privacy and security requirements and principles, and resources within CMS.

1.4. RoadmapFuture iterations of the Privacy Handbook will include, but are not limited to the following:

Privacy FAQ’s/ Case Studies General Data Protection Regulation (GDPR) Privacy Incident Reporting SORN Consolidation Update Role and Responsibilities

o Office of General Counselo HHS Privacy Officero Office of Management and Budgeto Office for Civil Rightso HHS Integrity Board

Privacy Handbook 2Version 1.0 December 31, 2018


2. How to Use the Privacy HandbookThe Privacy Handbook is designed to help users identify documents they need to create prior to disclosing PII/PHI. It provides information on how to develop privacy-related notices and agreements, provides examples and templates for each type of document, and shows users where to find further information. Sources of in-depth information about the requirements that drive the content and scope of each type of notice or agreement include the CMS Information System Security and Privacy Policies (IS2P2), the CMS Acceptable Risk Safeguards (ARS), and the CMS Risk Management Handbook (RMH).

The Handbook guides the user through the following four-step process, which should be followed in order:

1. Answer the “Privacy Trigger Questions”2. Review the “One-Pager” for each relevant type of document3. Follow the Standard Operating Procedure for creating each type of document4. Use the supplied template as a guide for creating each type of document

2.1. Privacy Trigger QuestionsUsers of the Privacy Handbook should first consider the “Privacy Trigger Questions,” listed in Table 1 (see Section 4, below). The table assists users in determining the necessary privacy documents they must complete or update to meet statutes, standards, and requirements.

As can be seen in Table 1, some program activities or information systems require multiple documents, while for other activities and systems, none of these notices or agreements is applicable. Users of the Privacy Handbook should review these questions periodically; when a change occurs that affects how PII/PHI is collected, used, stored, transmitted, or disclosed; and when there is a change in the risk to the privacy or security of any PII/PHI.

2.2. One-PagersThe one-pagers are summaries that give users with an overview for each type of privacy document. They provide the information that users need to understand the purpose of each document, why it is necessary, the process used to create the document, where to go for more information about each document, and responses to frequently asked questions about each document.

2.3. Standard Operating ProceduresAfter users have reviewed the one-pager for a document type, they should proceed to the Standard Operating Procedures for that document type. Users may choose to print out the Standard Operating Procedure and use it as a checklist to track progress for completing the necessary steps to create the relevant notice or agreement.

2.4. TemplatesThe Privacy Handbook contains a template for each type of service line and agreement. Each template is an example of the document and includes required information. The template often



contains annotations to advise the user on how to customize the document to address a specific IT system or business process.



3. Roles and Responsibilities While primary responsibility for developing these documents resides with the relevant Business Owner or Project Manager, the user may require the input, assistance, or action of persons in other roles across the organization. In this section, responsibilities for creating these documents are described for each relevant role.

These roles and responsibilities are specific to the activities in this Handbook. A comprehensive list of information security and privacy roles and responsibilities for CMS stakeholders can be found in the HHS Information System Security and Privacy Policy (IS2P) and CMS IS2P2.

3.1. Program ExecutiveThe Program Executive should be an agency official (federal government employee) and should fulfill all the responsibilities identified in the HHS IS2P and CMS IS2P2. According to the HHS IS2P, the Program Executive should ensure the security and privacy requirements for information systems are planned, documented, and integrated from project inception through all the phases of the project's lifecycle. In terms of the processes and documents addressed in the Privacy Handbook, these responsibilities may require the Program Executive to:

Ensure adequate resources are available to identify the need to execute each document Ensure that processes exist and are being followed to create, finalize, and update each

type of document, as needed, at each appropriate phase of the CMS XLC Ensure that public documents are completed, published, and made available Ensure records are maintained demonstrating that these formal procedures have been

followed and have resulted in the completion of these documents

For some of these documents, the final signature, indicating acceptance and approval, will be the responsibility of the Program Executive.

3.2. Portfolio LeadThe Portfolio Lead works with the Portfolio Team to manage the cybersecurity and privacy risk for operating CMS information systems and protecting CMS information. The Portfolio Team for each CMS IT system consists of the Cyber Risk Advisor (CRA), Privacy Advisor, Business Owner, and Information System Security Officer (ISSO). The Portfolio Lead is responsible for coordinating their efforts related to an IT system. In terms of the Privacy Handbook, the Portfolio Lead may be responsible to:

Ensure the Business Owner has identified all privacy-related agreements and notices required for a particular IT system

Review agreements and notices related to an existing system and determining/verifying if updates are necessary

Coordinate meetings of the Portfolio Team and ensuring that addressing agreements and notices are included in meeting agendas

Maintain a schedule for creating or revising agreements and notices Review final drafts of agreements and notices before they are shared with Division

Directors for approval



3.3. Information System Owner The CMS ISO should be an agency official (federal government employee) and should fulfill all the responsibilities identified in the HHS IS2P (“System Owner”) and CMS IS2P2 (“Information System Owner”). Relative to the Privacy Handbook, these responsibilities may require the ISO to coordinate with the Data Guardian, Business Owner, Project Manager, CRA, Privacy Advisor, and ISSO to identify the types of information processed, assign the appropriate security categorizations to the information system(s), determine the privacy impacts, and manage information security and privacy risk. For many of the documents in the Privacy Handbook, the ISO should provide the user with clear, comprehensive information concerning the PII/PHI that is collected and how it is maintained, used, transmitted, and disclosed by the system.

3.4. Data GuardianThe Data Guardian should be an agency official (federal government employee) and should fulfill shared responsibilities with the CMS Business Owner identified in the HHS IS2P (“Data Owner/Business Owner”) and CMS IS2P2 (“Data Guardian”). In some cases, duties related to creating notices or agreements may be delegated to the Data Guardian. In terms of the processes and documents addressed in the Privacy Handbook, these responsibilities may require the Data Guardian to:

Coordinate with the ISO, Business Owner, Project Manager, CRA, Privacy Advisor, and/or ISSO to identify the types of information processed and provide information concerning the system and the PII/PHI it contains.

Coordinate with Contracting Officers (COs), Contracting Officers' Representatives (CORs), Program/Project Managers, the Chief Information Security Officer (CISO), ISO, and the Senior Official for Privacy to incorporate appropriate information security and privacy contracting language from relevant sources into each IT contract document.

Ensure transparency by providing the public with notices about what CMS does with beneficiary and other personal information.

3.5. Business OwnerThe CMS Business Owner should be an agency official (federal government employee) and should fulfill all of the responsibilities identified in the HHS IS2P (“Data Owner/Business Owner”) and CMS IS2P2 (“Business Owner”) in coordination with the Data Guardian. In terms of the processes and documents addressed in the Privacy Handbook, these responsibilities may require the Business Owner to:

Coordinate with the Data Guardian, ISO, CRA, Privacy Advisor, and ISSO to collect all information needed to complete all required documents and agreements, including the types of information processed, privacy and security safeguards that will protect the information, the laws or Executive Orders that provide CMS with the authority to collect the data, and any other information needed to complete privacy and/or security agreements or notices documented in the Handbook

Coordinate with the COs and CORs, Data Guardian, Program/Project Manager, the CISO, and the Senior Official for Privacy to ensure appropriate information security and privacy contracting language from relevant sources is incorporated into each IT contract



Where required, approve and sign agreements to indicate acceptance of their terms Where required, serve as the point of contact who is the focal point for questions about

the information system Ensure the procedure for each agreement and notice has been completed correctly and

comprehensively Seek assistance and input when necessary to complete any agreement, notice, or other

privacy or security compliance document Manage and approve all uses and disclosures of data from CMS programs or systems that

are permitted by routine use under CMS SORNs through appropriate vehicles to authorize or deny the release of PII/PHI.

Establish and revise, in coordination with the Privacy Act Officer, SORNs and CMAs in accordance with the established procedures.

3.6. Project ManagerIn reference to the content of the Privacy Handbook, the Project Manager may be delegated responsibility for performing the duties of the Business Owner; or Project Managers may be responsible for the notices and agreements concerning PII/PHI if the underlying business process does not involve an IT system and is not the responsibility of a Business Owner. When a Project Manager is responsible for any activity involving PII/PHI, they will have the same (or the equivalent) responsibilities as the Business Owner.

3.7. Privacy AdvisorThe CMS Privacy Advisors establish and implement enterprise-wide security and privacy policy consistent with federal requirements. Privacy Advisors influence the proper planning and management of CMS data and IT systems and safeguard CMS information and information systems. In terms of the processes and documents addressed in the Privacy Handbook, these responsibilities require the Privacy Advisor to:

Provide subject matter expertise to Business Owners or Project Managers on identifying the requisite document(s) for their business or project

Provide subject matter expertise on where and how the Business Owner or Project Manager can locate any information needed to complete privacy-related agreements and notices

Assist Business Owners or Project Managers in reviewing and updating privacy-relevant agreements and notices

Monitor privacy risks for all information systems by reviewing all information security and privacy artifacts and providing recommendations for addressing risks to the Business Owner, ISO, and/or senior management, as necessary

Support the implementation of privacy requirements and controls as CMS information systems are designed, operated, or updated



3.8. Information System Security OfficerThe CMS ISSOs may be either a federal government employee or a contractor and should fulfill all the responsibilities identified in the HHS IS2P (“ISSO”) and CMS IS2P2 (“Information System Security Officer”). In terms of the processes and documents addressed in the Privacy Handbook, these responsibilities may require the ISSO to:

Coordinate with the Data Guardian, ISO, CRA, Privacy Advisor, Business Owner, and Project Manager to collect all information needed to complete all required documents and agreements, including the types of information processed, privacy and security safeguards that protect that information, the laws or Executive Orders that provide CMS with the authority to collect the data, and any other information needed to complete privacy and/or security agreements or notices

Coordinate with the Chief Information Officer (CIO), CISO, Senior Official for Privacy, Data Guardian, and Website Owner/Administrator to ensure compliance with control family requirements on website usage, web measurement and customization technologies, and third party websites and applications, including completion of the required documents

Coordinate with the Data Guardian, ISO, Business Owner, Project Manager, Privacy Advisor, and CRA to meet all collection, creation, use, dissemination, retention, and maintenance requirements for PII/PHI in accordance with the Privacy Act, E-Government Act, and all applicable guidance.

3.9. Contracting Officer and Contracting Officer's RepresentativeThe CMS CO and COR should be agency officials (federal government employees) and should fulfill all of the responsibilities identified in the HHS IS2P, Appendix A, Section 27 (CO and COR). The responsibilities of the CMS CO and COR should include but are not limited to the following:

Ensure the CISO, Senior Official for Privacy, and Data Guardian are consulted during contract development

Ensure the latest information security and privacy contract language is included in all contracts, as applicable



4. Trigger QuestionsThe Trigger Questions in Table 1 allow the user to identify necessary agreements and notices. If the user answers “Yes” to any of the Privacy Trigger Questions, they should create the type of document listed at the top of the table column in which “Yes” is found. Some program activities and/or systems require multiple documents; other activities or systems may not require any of these agreements or notices.

Documents to Consider

SORN CMA IEA ISA TPWA

Relevant Relevant Relevant NA Relevant

NA NA NA Yes NA

Yes Relevant NA NA NA

Relevant Yes NA NA NA

Relevant NA NA NA Yes

Relevant NA Yes NA NA

Table KeyDocuments: Determinations:CMA Computer Matching Agreement Yes The document type at the top of the IEA Information Exchange Agreement column is needed.ISA Interconnection Security Agreement Relevant User should consider other questionsSORN Systems of Records Notice to determine whether the document

TPWA type at the top of the column is needed.

NA Not Applicable. This response does not impact whether the document at the top of the column is needed or not.

Questions to Ask

Will this activity require CMS to collect, use, or disclose PII or PHI?

Will CMS create a direct connection between any of its IT systems and any IT system with a different Authorizing Official, for the purpose of sharing (any) data and other information resources?

Is information maintained about an individual in a System of Records and routinely retrieved by a personal identifier?

Is the information about individuals matched by use of a common personal identifier?

Is the website or application outside of the CMS domain and managed by a third-party?Will CMS disclose PII to an external federal agency, state government agency, CMS contractor, CMS grantee, OR private sector organization; and, is the purpose of the disclosure not related to either research, nor to support a matching program?Note: All questions assume that a “disclosure” is to a system outside of CMS. Disclosures may be to

another federal agency, a state agency, or in some cases to a private or commercial recipient.

Third-Party Websites and Applications

Table 1. Trigger Questions to Determine Required Documentation



5. System of Records Notice The Privacy Act requires a federal agency to publish a notice in the Federal Register for each system of records that it maintains. A system of records is a group of records under the control of an agency from which information about individuals is retrieved by the name of the individual or by some other personal identifier assigned to the individual. A System of Records Notice (SORN) describes the purposes for which CMS collects the records; describes the categories of persons and records that the system of records covers; identifies the official who is responsible for the particular system of records; and provides instructions persons should follow to determine if a system of records contains a record about them and how they can obtain a copy of any such record. The SORN also discusses to what entities and persons CMS may disclose the information that CMS collects.

When Business Owners or Project Managers must determine if a SORN is necessary, they will often need to determine if a system of records is already addressed by an existing SORN. CMS currently maintains systems of records containing information about program applicants, enrollees, beneficiaries, providers, CMS employees, and other categories of individuals. Business Owners may find a list of current CMS SORNs at HHS’s website, with links to the full documents as they were published in the Federal Register, at https://www.hhs.gov/foia/privacy/sorns/cms-sorns.html.

The SORN serves as a notice to the public regarding the rights and procedures of the Privacy Act for accessing and correcting information about individuals maintained by an agency. The Office of Management and Budget (OMB) provides further guidance for agencies on the development of SORNs in Circular No. A-108, Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act (reissued December 23, 2016). Extensive additional guidance on developing SORNs and the Privacy Act generally is available at the Department of Justice’s Privacy Act web site at https://www.justice.gov/opcl/privacy-act-1974.

5.1. SORN One-PagerThe image below is a one-page review of information that will help a CMS Business Owner or Project Manager determine whether to complete or modify a SORN. From the SORN One-Pager, users should be able to quickly understand the purpose of the SORN and why it is necessary; the process to create or modify a SORN; and where to go for more information about the SORN and get responses to frequently asked questions about the SORN. (You may click on the image of the SORN One-Pager below to access a full-page, printable copy.)


https://www.justice.gov/opcl/privacy-act-1974

https://www.hhs.gov/foia/privacy/sorns/cms-sorns.html


Figure 1. SORN One-Pager

5.2. SORN Standard Operating ProcedureThe procedure in the table below provides a breakdown of the steps necessary to develop a new SORN or modify an existing SORN.


Centers for Medicare & Medicaid Services Interconnection Security Agreement

Table 2. SORN Review Standard Operating Procedure

SORN Standard Operating Procedure (SOP) and TimelineLast Updated: November 21, 2018

Trigger for Review:

Business Owner or Project Manager determines that an IT system or electronic records collection contains information about individuals and may require a SORN.

☐

Business Owner determines that their business unit will make a significant change in how it will collect or use information about individuals that may require modifications to the SORN (e.g., because of an impact to the privacy or security concerns of the system).

☐

Date of last SORN review approaches two years ☐ HHS or OMB directs CMS to modify an existing SORN (due, e.g., to a new statutory or regulatory requirement). ☐ The Privacy Advisor reviews the SORN pursuant to Privacy Continuous Monitoring. ☐

SORN Name: Review Date:

CMS Privacy Handbook 12Version 1.0 December 31, 2018

Centers for Medicare & Medicaid Services Information Exchange Agreement

StepActio Duration Start Date

End Date Status

1.

The CMS Privacy Advisor (Privacy Advisor) schedules a kick-off meeting with the CMS Business Owner (Business Owner) to discuss the following agenda:

Identify Points of Contact for the development of the SORN Discuss the activity taking place that triggered the review Review the SOP and timeline for establishing a new SORN

or modifying an existing SORN Discuss the proposed changes to the SORN (if a SORN

exists) Establish next steps and recurring touch point meetings

7 Days

2.

The Privacy Advisor begins an analysis of documents and information. To begin gathering information for a new SORN, or to identify information that must be updated in an existing SORN, the Privacy Advisor reviews the system of records for:

Existing and/or proposed data collections Other SORN(s) that may be implicated in this system of

records activity

The Privacy Office, along with the CRA, reviews the existing PIA and the Security Impact Analysis (SIA) (if applicable).

14 Days



3.

The Business Owner collaborates with program stakeholders and program legal counsel develop drafts of the SORN, Narrative Statement, and Transmittal Letters for the Administrator of the Office of Information and Regulatory Affairs within OMB, Chair of the House Committee on Oversight and Government Reform, and to the Chair of the Senate Committee on Homeland Security and Governmental Affairs.

The Business Owner sends the draft documents to the Privacy Advisor/Office.

14-21 Days

4.

The Privacy Advisor forwards the package of final draft documents to the HHS Privacy Act Officer. The HHS Privacy Act Officer coordinates with HHS General Law Division (GLD) for a legal review. The HHS Privacy Act Officer provides comments back to the Privacy Advisor, which are then provided to the Business Owner.

14 Days

5.The Business Owner and any stakeholders review HHS comments, make updates (as necessary), and send the updated package back to the Privacy Advisor.

7 Days

6.

The Privacy Advisor confirms that the document package is complete and finalized and prepares the SORN for approval.

The red folder sign-off sheet is directed to: CMS Privacy Act Officer CMS Division Director CMS Senior Official for Privacy

Upon signature of approval, the Privacy Advisor acquires the fully approved SORN.

7 Days



7.The Privacy Advisor sends the approved package, consisting of SORN, Narrative Statement, and Transmittal Letters, to the HHS Privacy Act Officer.

7 Days

8.

The HHS Privacy Act Officer submits the SORN, Narrative Statement, and OMB cover letter to OMB using an information system called ROCIS.

The HHS Privacy Act Officer verifies the identity of the House and Senate Committee chairs, and then mails the appropriate documents (Narrative Statement, SORN, and the correct cover letter) to recipients at the House and Senate.

All documents are submitted at the same time to run the time frames concurrently.

The HHS Privacy Act Officer informs the CMS Privacy Office when OMB approves the SORN. If no comments are received after 30 days, the SORN is permitted to be sent to the Federal Register for publication.

30 Days

9.

The Privacy Advisor digitally signs the SORN and sends it to the Federal Register.

The Federal Register accepts the electronic document and displays CMS’s SORN in the Public Inspection Room for two business days. On the third business day, the SORN is published in the Federal Register.

3 Day



10.

Once published in the Federal Register, a 30-day public comment period is required by law. Any comments received during the 30-day public comment period are reviewed by the Privacy Advisor.

The Privacy Advisor forwards any program specific questions to the Business Owner for a response, and the Business Owner coordinates as needed with the Privacy Officer.

30 Days

11.

The SORN becomes effective 30 days after publication in the Federal Register.

The Privacy Advisor notifies the Business Owner and all stakeholders of the effective date of the SORN.

HHS loads the approved SORN to the HHS website.

The Privacy Advisor files a hard copy of the approved package in the DSPPG paper files.

1 Day

Supplemental Guidance for SORNWhen a federal agency maintains information about an individual in a system of records and retrieves the information by a personal identifier, the agency must publish a SORN in the Federal Register. SORNs are required for new systems of records and when making significant changes to an existing system of records.

SORNs identify the purpose of a system of records (SOR), identify which individuals are covered by information in a SOR, identify the categories of records that are maintained about the individuals, identify how the information is shared by the agency (i.e., under



“routine uses”), inform the public of the existence of SORs, and notify the public of their rights under the Privacy Act for accessing and correcting information about themselves maintained by the agency.

SORNs must be created or updated when changes occur to CMS’s IT systems, when programs begin or change their activities related to SORNs, or when legal or regulatory requirements require changes. New SORNs are created to accommodate new legislation, programs, or changes in the uses of data collections. Timelines for various steps of creating or renewing a SORN are provided in the SORN Standard Operating Procedure. Some of those time periods are set by law; others, however, may be expedited if the development of the SORN is a high CMS priority, and the timeframes provided are approximate. The overall process, though, often takes 180 days or more.

For additional information and specific details related to SORNs, including required templates, submission guidelines and references to additional OMB guidance materials see OMB Circular A-108, “Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act.” SORN Template

A template for creating a SORN is included in Appendix D.

CMS Privacy Handbook Version 1.0 December 31, 2018


6. Computer Matching Agreement The Computer Matching and Privacy Protection Act of 1988 requires agencies engaged in computer matching programs to provide notice to individuals if their information is being computer matched; to allow individuals the opportunity to refute adverse information before having a benefit denied or terminated; and to establish Data Integrity Boards (DIBs) to oversee computer matching programs.

6.1. CMA One-PagerThe image below is a one-page review of information that will help a CMS Business Owner or Project Manager determine whether to complete or modify a CMA. From the CMA One-Pager, users will be able to quickly understand the purpose of the CMA and why it is necessary; the process that should be used to create the CMA; and where to go for more information about the CMA and to get responses to frequently asked questions about the CMA. (You may click on the image of the CMA One-Pager below to access a full-page, printable copy.)



Figure 2.CMA One-Pager

6.2. CMA Standard Operating Procedure The procedure in the table below gives a detailed review of the actions necessary to complete a new CMA or modify an existing CMA. Table 3. CMA Standard Operating Procedure

CMA Standard Operating Procedure (SOP) and TimelineLast Updated: August 9, 2018

Trigger:

Request from another federal or state agency for CMS data ☐

A CMS program that requires data from another federal or State agency ☐

When the CMA is expiring ☐

Step Action Time to Complete

Start Date

End Date Status

1.The Privacy Office receives the request to develop or update a CMA from the Business Owner or based on the expiration schedule and notifies the associated Privacy Advisor.

1 Day

2.

The Privacy Advisor conducts internal review and looks at the new or existing CMA requirements, new materials related to the CMA (if applicable), and routine uses for the SORNs that may be implicated by the activity.

14 Days




3.

The Privacy Advisor organizes a meeting with the Business Owner and, potentially, the Data Guardian (DG) to determine the scope and complexity of the CMA activity, determine with whom the information will be shared, and identify the purpose for data sharing. The Privacy Advisor also identifies any input or collaboration needed with other stakeholders.

The timeline and steps in the process are reviewed and both parties agree to adhere to the scheduled time frames.

Note 1: A minimum of 240 days is required to complete a new or reestablished CMA for 18 months.

Note 2: To extend or recertify the CMA, the Business Owner initiates the renewal process at least 90 days before the CMA expires.

The Privacy Handbook provides the Business Owner with the templates and references needed to complete the CMA activity.

Follow-up meetings or check-in points are negotiated and scheduled according to the completion timeline to maintain a collaborative process for the CMA activity.

7 Days




4.

The Business Owner works with Privacy Advisor to complete the CMA draft, which includes:

Draft a new CMA or update the existing CMA Draft the transmittal letters to both Houses of Congress

and OMB Draft the Federal Register notice Draft a narrative statement for the new or updated CMA Draft the cost-benefit analysis (CBA) (if necessary)

The Business Owner works with the stakeholders and Program Office of the General Counsel to ensure that all sections of the CMA are complete and accurate.

If the CMA is between federal agencies, and CMS is the data recipient, the CMS Business Owner is responsible for preparing the CMA document package. In either case, the source agency negotiates terms with the recipient agency, and CMS coordinates these negotiations through the Privacy Advisor and the Privacy Office. The source agency and recipient agency must agree on how they will each acquire DIB concurrence and signoff. They must agree on the order in which each agency’s DIB will review the CMA, and sign off on it. While the agencies’ DIBs may review the CMA at the same time, in all cases DIBs must maintain version control throughout their review processes.

If the CMA is between CMS and state agencies, the CMS Business Owner prepares the CMA document package.

90 Days

5. The Privacy Office shares the draft with HHS Privacy Act Officer for preliminary review and comment.

14 Days




6.

The Privacy Advisor produces and submits final drafts of the entire package to the Business Owner. The Privacy Advisor and the Business Owner agree on the final package.

The Privacy Advisor prepares the final package for internal sign-off by creating a clearance folder, which includes:

CMA CBA

The Privacy Advisor prepares the clearance folder signature jacket and is directed to:

Privacy Office Division Director Senior Official for Privacy

14 Days

7.

The Privacy Advisor submits the CMA to the DIB. The DIB reviews the agreement and provides comments to the Privacy Office, if necessary.

See Step 4 for information concerning the order of securing concurrence from both DIBs, if the CMA is between two agencies.

60 Days

8.

After the HHS DIB approves and signs the CMA, HHS submits the CMA to OMB.

HHS mails the CMA, CBA, transmittal letters, and the Federal Register Notice to both houses of Congress.

All documents are submitted at the same time to run the time frames concurrently as much as possible.

30 Days




9.

After 30-day review period (if OMB has not made comments, the CMA can be published), the Privacy Office signs and submits the Federal Register Notice via the online portal: https://piv.idmanagement.gov/userguides/signworddoc-ofr/#main-content. The Federal Register accepts the electronic document and displays the document in the Public Inspection Room for two business days. On the third business day, the notice is published in the Federal Register.

Once published in the Federal Register, a 30-day public comment period is required by law. Any comments received are reviewed by the CMS Business Owner. The Business Owner should respond to any comments received during the 30-day public comment period.

30 Days

10.

The CMA becomes effective 30 days after publication in the Federal Register. The agreement and the Federal Register Notice are published on the HHS Privacy website: https://www.hhs.gov/foia/privacy/cmas/index.html. The final package is uploaded to SharePoint and the hard copy is retained in DSPPG files.

7 Days

Supplemental Guidance for CMAA Computer Matching Agreement (CMA) is a written agreement that establishes the conditions, safeguards, and procedures under which a federal agency agrees to disclose data with another federal or State agency where there is a computerized comparison of two or more automated System of Records (SORs). Computer matching occurs when the shared information about an individual is retrievable by use of a personal identifier. The Computer Matching and Privacy Protection Act require agencies engaged in computer matching activities to provide notice to individuals if their information is being computer matched, allow individuals the opportunity


https://piv.idmanagement.gov/userguides/signworddoc-ofr/#main-content

https://piv.idmanagement.gov/userguides/signworddoc-ofr/#main-content


to refute adverse information before having a benefit denied or terminated, and establish Data Integrity Boards (DIBs) to oversee computer-matching activities.

The Privacy Act requires the agency to notify the public by publishing a notice in the Federal Register (FR) of the establishment or alteration of a computer matching program. If the match is between two federal agencies, both agencies have a role in establishing, or altering the CMA. In CMS, the Business Owner of the system of records used in the match works with the DSPPG Privacy Office (Privacy Advisor and Privacy Office) to establish, extend or renew a CMA. The DSPPG Privacy Office has a direct and controlling role in ensuring that CMS data involved in the match are disclosed under proper legal authority; PII is protected according to the legal requirements of the Privacy Act and the Health Insurance Portability and Accountability Act (HIPAA Privacy rule; and all OMB requirements for notice are met and timely published before the matching activity can begin.

Under the Privacy Act, an initial (new) CMA remains in effect for a period not to exceed 18 months, as the DIB determines is appropriate. However, the DIB may renew the agreement for a period not to exceed 12 additional months if the program will be conducted without any changes and each party to the agreement certifies to their respective DIB in writing that the program has been conducted in compliance with the CMA.

Specific templates approved by the HHS DIB that include the most recent CMA and CBA documentation requirements, sample letters, and narrative statements are provided by the PO at the beginning of the CMA drafting activities. The templates and guidance for the development of the CMA package are based on the most current iteration of the OMB Circular A-108 document.

The DSPPG Privacy Advisor and CMS Privacy Office, CMS Cyber Risk Advisor, and the Business Owner, including the component level ISSOs and Data Guardian, form the team that will be involved in the process of vetting and assuring the privacy, security, and appropriate use of the data in a CMA. The Privacy Advisor has the role of assisting the Business Owner and has the responsibility to track and monitor progress and provide guidance to the component during this process.

Business Owners are responsible for drafting the CMA and are required to develop the required narrative statement, Federal Register Notice, and Congressional transmittal letters. Additionally, the initial 18-month CMA requires the development of a CBA to be included in matching agreements as justification for the proposed matching program. The Business Owner may also need to create a Data Use Agreement (DUA), which tracks the CMS disclosures of PII held in the system of records that should be executed prior to the disclosure of data. Finally, the Business Owner participates in creating where applicable, an Interagency Agreement (IAA). The IAA is a reimbursement agreement that is used by CMS as a financial document that contains the financial data and billing codes necessary to satisfy reimbursement requirements defined in the CMA.



If a non-federal agency is the data recipient from the match, the Privacy staff (the Privacy Advisor and Privacy Office) works with the Business Owner to ensure that all activities related to creation of the CMA, narrative statement, congressional transmittal letters, CBA, and the Federal Register Notice are completed appropriately.

Alternatively, if the data recipient is a business associate of another federal agency, the matching agreement process should have primary participation by the federal agency, with the business associate in a supporting role to provide insight in the operational aspects. In addition, the system of records that is being used in the matching program should have an existing routine use that would support the foundational rationale for the proposed matching program.

Template Development for CMAThe CMA Standard Operating Procedure includes a template and proposed language for a complete CMA package required to be developed and submitted to the HHS DIB and, subsequently to OMB and the Federal Register. The recipient agency is responsible for the development of the CMA package. The following elements are required for an 18-month new or reestablished CMA:

1. Computer Matching Agreement (CMA)o The agreement follows a strict template outlined in OMB Circular A-108.

2. Cost Benefit Analysis (CBA)o The CBA serves as an attachment to be included within the agreement and is

required for the 18-month new or renewal of the matching program. The potential extension of the matching program for 12 months does not require a CBA to be included, as it is assumed that the CBA is still relevant as a justification for the program.

3. Narrative Statemento The narrative statement provides a brief overview of the proposed matching

program, referring to the other materials in the report without simply restating information provided in those materials.

4. Federal Register Matching Noticeo The matching notice describes the established, re-established, or significantly

modified matching program and is used as a description in the Federal Register entry.

5. HHS Transmittal Letters (House, Senate, OMB)o The letter to the House of Representatives is based on the transmittal letter

template and is addressed to the Chairman for the Committee on Oversight and Government Reform.

o The letter to the Senate is based on the transmittal letter template and is addressed to the Chairman for the Chairman, Committee on Homeland Security and Governmental Affairs.

o The letter to the Senate is based on the transmittal letter template and is addressed to the Administrator of the Office of Information and Regulatory Affairs within OMB.



For a 12-month CMA extension/recertification, the package consists of the CMA, which details the modifications made to the agreement itself, including points of contact. Documents 2, 3, 4, and 5 in the list above are NOT required for the extension/recertification.

6.3. CMA Federal Register Publication Template As discussed in the CMA Standard Operating Procedure, the CMA should be published in the Federal Register. A template for the CMA, in the format required for publication in the Federal Register, is included in Appendix E .

6.4. CMA Letter to House Committee TemplateAs discussed in the CMA Standard Operating Procedure, the process of creating a CMA requires CMS to provide a letter to the House of Representatives Committee on Oversight and Government Reform. The template for this letter is included in Appendix F .

6.5. CMA Letter to Senate TemplateAs discussed in the CMA Standard Operating Procedure, the process of creating a CMA requires CMS to provide a letter to Senate Committee on Homeland Security and Governmental Affairs. The template for this letter is included in Appendix G .

6.6. CMA Letter to OMB TemplateAs discussed in the CMA Standard Operating Procedure, the process of creating a CMA requires CMS to provide a letter to the Office of Management and Budget (OMB). The template for this letter is included in Appendix H .

6.7. CMA Narrative Statement TemplateAs discussed in the CMA Standard Operating Procedure, the process of creating a CMA requires CMS to create a narrative statement that will form part of the CMA “packet” to be reviewed and approved by several stakeholders. The template for the narrative statement is included in Appendix I



7. Information Exchange AgreementAn IEA is executed between CMS and a party requesting PII/PHI from CMS. It establishes the terms, conditions, safeguards, and procedures under which CMS is willing to disclose PII/PHI. The IEA documents the specific PII/PHI elements being shared, the purpose for which each PII/PHI element will be shared, the legal authority for sharing, and the security and privacy obligations of the recipient. CMS uses IEAs when sharing PII/PHI unless CMS will be sharing PII/PHI for a computer matching program, in which case a CMA is required instead.

7.1. IEA Review One-PagerThe image below is a one-page review of information that will help a CMS Business Owner or Project Manager determine whether to complete or modify an IEA. From the IEA One-Pager, users can quickly understand the purpose of the IEA, why it is necessary, the process that should be used to create the IEA, and where to go for more information about the IEA and get responses to frequently asked questions about the IEA. (You may click on the image of the IEA One-Pager below to access a full-page, printable copy.)

Figure 3. IEA One-Pager



7.2. IEA Standard Operating Procedure The procedure in the table below gives a detailed review of the actions necessary to complete a new IEA or modify an existing IEA.Table 4. IEA Standard Operating Procedure



IEA Standard Operating Procedure (SOP) and TimelineLast Updated: August 9, 2018

Triggers for Review:

Request from federal or state agencies, and/or third-parties to share CMS personally identifiable information (PII) or protected health information (PHI)

☐

CMS program needs PII or PHI from another federal or state agency, and/ or third-party ☐ When an IEA expires (after 5 years) for renewal ☐

Name: Review Date:

StepAction Duration Start Date End Date Status

1.

The Privacy Office receives the request to develop or renew an IEA from the Business Owner and notifies the portfolio Privacy Advisor.

1 day

2.The Privacy Advisor conducts internal review and looks at new or existing IEA and new materials related to the IEA (if applicable).

14 Days




3.

The Privacy Advisor organizes a meeting with the Business Owner and potentially the Data Guardian (DG) to determine the scope and complexity of the IEA activity, determine with whom the information will be shared, and identify the purpose for data sharing. The Privacy Advisor also identifies any input or collaboration needed with other stakeholders.

The timeline and steps in the process are reviewed and both parties agree to adhere to the scheduled timeframes.

7 Days

4.

The Business Owner works with the Privacy Advisor to complete IEA draft, which includes:

Draft a new IEA or update the existing IEA

The Business Owner works with the stakeholders to ensure that all sections of the IEA are complete and accurate.

If the IEA is between federal agencies and CMS is the data requester, the CMS Business Owner is responsible for preparing the IEA. The disclosing agency negotiates terms and coordinates through the Business Owner.

If the IEA is between CMS and state agencies, the CMS Business Owner prepares the IEA.

21 Days




5.

The Privacy Advisor produces and submits final drafts of the IEA to the Business Owner. The Privacy Advisor and the Business Owner agree on the final IEA and share it with external parties to the agreement, who return the signed IEA to the Privacy Office.

14 Days

6.

The Privacy Advisor prepares the IEA for internal sign-off by creating a clearance folder that is directed to:

Privacy Act Officer DSPPG Division Director Senior Official for Privacy

Once the IEA is signed by all parties, the effective date is established for the agreement.

14 Days

7.The Privacy Advisor sends the signed IEA to the Business Owners, stakeholders, and parties to the agreement.

1 Day

8. The final IEA is uploaded to SharePoint and the hard copy is retained in the DSPPG files. 1 Day



Supplemental Guidance for IEAAn Information Exchange Agreement is required for a CMS Business Owner to share PII with an external third-party organization for non-research related purposes. The external organization can be a federal1 or state agency from the public sector or a privacy-sector organization. CMS contractors or grant recipients are also types of third-party organizations that require an IEA. The IEA is executed among the CMS Business Owner, the CMS CISO, and the external organization who will receive the PII.

The Business Owner is responsible for working with the third-party organization to make sure the IEA template is complete. The following are the major steps in completing a template: validate that the third-party is authorized to receive the PII by identifying the applicable SORN(s); identify the purpose, uses, and minimum PII necessary to address the third-party organization’s need; coordinate with other CMS stakeholders to locate the data and define how it will be transmitted securely; and detail how the security and privacy of the PII will be protected in accordance with the Health Information Portability and Accountability Act (HIPAA) and CMS policy and standards. After these steps have been addressed and the IEA is executed, CMS will be able to share minimally necessary PII with the third party with assurance that the third party will adequately safeguard the PII.

After the IEA has been executed, the Business Owner needs to work with the Office of Acquisitions and Grants Management to execute a Data Use Agreement. This should be done prior to sharing PII with the third-party organization.

A template for the IEA is included in Appendix J .

1 If a CMS is sharing PII as part of a “matching program,” then a Computer Matching Agreement is needed instead of an IEA. A matching program is any computerized comparison of two or more automated systems of records or a system of records with non-federal records used for the purpose of:

• Establishing or verifying the eligibility of, or continuing compliance with statutory and regulatory requirements by, applicants for, recipients or beneficiaries of, participants in, or providers of services with respect to, cash or in-kind assistance or payments under federal benefit programs; or

• Recouping payments or delinquent debts under such federal benefit programs

A matching program may also be a computerized comparison of two or more automated federal personnel or payroll systems of records or a system of federal personnel or payroll records with nonfederal records. A number of exceptions to the definition of matching program are provided by the Computer Matching and Privacy Protection Act.



8. Interconnection Security Agreement The Interconnection Security Agreement (ISA) is a document that regulates security-relevant aspects of an intended connection between an agency and an external system. It regulates the security interface between any two systems operating under two different distinct authorities. It includes a variety of descriptive, technical, procedural, and planning information. It is usually preceded by a formal Memorandum of Agreement (MOA)/Memorandum of Understanding (MOU) that defines high-level roles and responsibilities for managing a cross-domain connection.

8.1. ISA One-PagerThe image below is a one-page review of information that will help a CMS Business Owner or Project Manager determine whether to complete or modify an ISA. From the ISA One-Pager, users can quickly understand the purpose of the ISA and why it is necessary, the process that should be used to create the ISA, and where to go for more information about the ISA and get responses to frequently asked questions about the ISA. (You may click on the image of the ISA One-Pager below to access a full-page, printable copy.)



Figure 4. ISA One-Pager

8.2. ISA Standard Operating ProcedureThe procedure in the table below gives a detailed review of the actions necessary to complete a new ISA or modify an existing ISA.



Table 5. ISA Standard Operating Procedure

ISA Standard Operating Procedure (SOP) and TimelineLast Updated: August 9, 2018

Trigger for Review:

Business Owner or Information System Security Officer (ISSO) initiates an ISA as the result of a new interconnection with a non-CMS party ☐

Business Owner or ISSO reviews an ISA as the result of a change to the data being transferred with a non-CMS party ☐

Business Owner or ISSO initiates a renewal of an ISA that is expiring ☐ Business Owner or ISSO initiates an extension of an ISA that is expiring ☐ Business Owner or ISSO reviews the protections being deployed to ensure the interconnection is monitored for

unauthorized use and transmissions ☐

Business Owner or ISSO reviews what National Institute of Standards and Technology (NIST) Federal Information Processing Standard (FIPS) 140-2 approved encryption will be used to protect the interconnection ☐

Name:

Review Date:

StepAction Duration Start Date

End Date Status

1.

The CMS Business Owner receives a request for data that requires a new system interconnection. The CMS Business Owner is responsible for the management and oversight of the CMS information system that requires the interconnection with the non-CMS Organization.

The Business Owner serves as the primary point of contact for the CMS information system.

7 Days


Centers for Medicare & Medicaid Services Other Agreements

ISA Standard Operating Procedure (SOP) and TimelineLast Updated: August 9, 2018

2. The CMS Business Owner consults with the ISSO and reviews the requirements to establish an interconnection with the non-CMS party 14 Days

3. The ISSO of the CMS system works with their counterpart at the non-CMS party to develop the ISA 35 Days

4. The CMS Business Owner and the non-CMS party Business Owner do the final review and sign off on the ISA when satisfied with its contents. 7 Days

Supplemental Guidance for ISAA system interconnection is defined as the direct connection of two or more IT systems for sharing data and other information resources. The ISA identifies the basic components of an interconnection, identifies methods and levels of interconnectivity, and discusses potential security risks associated with an interconnection. Significant benefits that can be realized through a system interconnection include reduced operating costs, greater functionality, improved efficiency, and centralized access to data. Interconnecting IT systems may also strengthen ties among participating organizations by promoting communication and cooperation.

Federal policy requires agencies to develop ISAs for federal information systems and networks that share or exchange information with external information systems and networks.

The ISA shall become effective upon the signature of the parties involved and remain in effect until terminated by either party. The ISA is subject to annual review and should be reauthorized when there is a modification to the security posture or during re-certification and re-accreditation. If one or both parties wish to terminate the agreement, they may do so upon 30-days written notice. In the event of a security incident or suspected incident, CMS has the right to immediately terminate the connection.

A template for the ISA is included in Appendix K .


Centers for Medicare & Medicaid Services

9. Third-Party Websites and Applications When CMS opts to use web-based technologies (including social media, advertising, and web analytics) to increase its transparency, encourage public participation, or collaborate on government business operations, the TPWA provides an analysis of privacy implications. Often the TPWA is abbreviated to just TPWA.

9.1. TPWA One-PagerThe image below is a one-page review of information that will help a CMS Business Owner or Project Manager determine whether to complete or modify a TPWA. From the TPWA One-Pager, users will be able to quickly understand the purpose of the TPWA and why it is necessary; the process that should be used to create the TPWA; where to go for more information about the TPWA; and responses to frequently asked questions about the TPWA. (You may click on the image of the TPWA One-Pager below to access a full-page, printable copy.)



Figure 5. TPWA One-Pager

9.2. TPWA Standard Operating ProcedureThe procedure in the table below gives a detailed review of the actions necessary to complete a new TPWA or modify an existing TPWA.



Table 6. TPWA Standard Operating Procedure

TPWA Standard Operating Procedure (SOP) and TimelineLast Updated: August 9, 2018

Trigger for Review: Introduction or change to third-party tools being used by a program, system, or process ☐

Privacy Advisor determines a TPWA is necessary for a given activity or IT system ☐

ISSO or Business Owner determines a TPWA is necessary for a given activity or IT system ☐

TPWA Name: Review Date:

Step Action Duration Start Date

End Date Status

1.

The ISSO or Business Owner contacts the designated CRA and Privacy Advisor to discuss the relevant activity or IT system and determine if a TPWA needs to be newly developed or updated to reflect a change to the system/tool.

If a TPWA is being updated, the CMA TPWA Manager downloads the existing TPWA from HHS and provides it to the Privacy Advisor.

7 Days

2.

The Privacy Advisor sends the TPWA template (in MS Word format) or the existing TPWA to the ISSO and Business Owner, also notifying the CRA for tracking purposes.

The Privacy Advisor requests that the TPWA be reviewed and edited to reflect the current state of the tool or that it be fully developed.

7 Days

3. The Business Owner develops/revises the TPWA and returns it to the Privacy Advisor for review.

During the development of the TPWA, the Business Owner and the Privacy Advisor communicate regularly on any questions regarding the

14 Days


TPWA Standard Operating Procedure (SOP) and TimelineLast Updated: August 9, 2018

TPWA responses.

4.

The Privacy Advisor reviews the revised/completed TPWA and provides comments to the Business Owner for any requested revisions or needed for clarifications.

Depending on the nature of the comments made by the Privacy Advisor, the Business Owner either may conduct an e-mail discussion or call for a meeting to address outstanding issues.

14 Days

5.

The Privacy Advisor sends the TPWA through the clearance process via a signature request (sometimes referred to as the “red folder” process) and through DSPPG/ISPG clearance to the Final Approver. The clearance process requires approval from the following parties: DSPPG/ISPG Director ISPG Senior Official for Privacy

21 Days

6.

The CMS TPWA Privacy Advisor sends to HHS through the HHS Security Data Warehouse for HHS review and publishing on the HHS website.

If HHS has comments or requires revisions to the TPWA, the comments will be communicated to CMS via email to be resolved ad hoc.

42 Days



Supplemental Guidance for TPWAPIAs are structured processes for identifying and mitigating privacy risks, including risks to confidentiality, within an information system. PIAs are also conducted on third-party websites and applications (including tools) that are utilized by CMS. CMS’s use of a third-party website or application (TPWA) can be covered in a single, separate TPWA. However, a CMS business component may prepare one PIA to cover multiple websites or applications that are functionally comparable, as long as the business component practices are substantially similar across each website and application. If CMS’s use of a website or application raises distinct privacy risks, then the CMS business component should prepare a TPWA that is exclusive to that website or application. This document provides an outline of the TPWA process, procedures, and layered guidance for both development and review.

A TPWA template is included in Appendix L .


10. Other Agreements Other required, legally binding agreements are administered by CMS’s Office of Acquisitions and Grants Managements (OAGM) and are executed as, or pursuant to, formal contracts with external entities. While federal law dictates the scope of these agreements, many of the particulars vary and may depend on whether the contract is for goods or services; whether the external party is performing work on behalf of CMS; or whether the activity concerns the delivery of healthcare treatment, payment, or operations. While some examples of such agreements are available, these agreements need to be drafted and executed with the assistance of OAGM. Short introductions to the most common types of contract-related agreements are below.

10.1. Data Use Agreement The Data Use Agreement (DUA) tracks disclosures of PII/PHI to third-parties to ensure that any transaction of data is compliant with the Privacy Act of 1974 and the HIPAA Privacy Rule. The DUA can involve third-party entities such as oversight agencies, federal agencies, state agencies, and research institutions. The DUA template and additional guidance can be found at CMS’s Researcher Data Assistance Center.

10.2. Inter-Agency AgreementCMS creates an Inter-Agency Agreement (IAA) whenever it agrees to provide materials, supplies, equipment, work, or services to assist another federal agency or department in accomplishing its mission. The IAA permits CMS to be reimbursed for the specified work or provisions. CMS uses the IAA when it provides or receives such support to or from any agency other than HHS or one of its other OpDivs. An Intra-Agency Agreement (IA) is a similar agreement used when an OpDiv or one of its components provides materials, supplies, equipment, work or services to any other HHS component so the component receiving the services may accomplish its mission.

10.3. Memorandum of UnderstandingA Memorandum of Understanding (MOU) defines the relationship of two or more federal partners that enter into a joint project or collaboration in which they each contribute their own resources. Federal policy requires that agencies develop ISAs or MOUs for system interconnections. CMS has established a standard that an ISA be employed when the system interconnection is between separate, but secure, networks, while a MOU is used for interconnections within the same secure network. A template for MOU s is available on CMS’s public website. The MOU is based on the NIST Special Publication (SP) 800-47, Security Guide for Interconnecting Information Technology Systems.

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Info-Security-Library-Items/CMS1223300.html

https://www.cms.gov/Research-Statistics-Data-and-Systems/Files-for-Order/Data-Disclosures-Data-Agreements/DUA_-_Forms.html


10.4. Memorandum of AgreementA Memorandum of Agreement (MOA) is similar to a MOU but defines the relationship of two or more federal partners that enter into a joint project or collaboration but do not exchange resources. A MOA should indicate how each agency will benefit from the agreement.

10.5. Other AgreementsMore information on these and any other agreements executed pursuant to Acquisitions and Grants Management is available from OAGM’s Customer Relations Group at: [email protected].


mailto:[email protected]

Centers for Medicare & Medicaid Services Points of Contact

Appendix A Acronyms

Acronym Definition

ARS Acceptable Risk Safeguards

CBA Cost/Benefit Analysis

CFACTS CMS Federal Information Security Modernization Act (FISMA) Controls Tracking System

CIO Chief Information Officer

CISO Chief Information Security Officer

CMA Computer Matching Agreement

CMS Centers for Medicare & Medicaid Services

CO Contracting Officer

COR Contracting Officer's Representative

CRA Cyber Risk Advisor

DG Data Guardian

DIB Data Integrity Board

DSPPG Division of Security, Privacy Policy, and Governance

DUA Data Use Agreement

FIPS Federal Information Processing Standards

FISMA Federal Information Security Modernization Act of 2014

FOIA Freedom of Information Act

GLD General Law Division

HHS Department of Health and Human Services

HIPAA Health Insurance Portability and Accountability Act of 1996

IA Intra-Agency Agreement

IAA Inter-Agency Agreement

IEA Information Exchange Agreement

IS2P HHS Information System Security and Privacy Policy

IS2P2 CMS Information System Security and Privacy Policy

ISA Interconnection Security Agreement

ISO Information Systems Owner



Acronym Definition

ISPG Information Security and Privacy Group

ISSO Information Systems Security Officer

IT Information technology

MARS-E Minimum Acceptable Risk Standards for Exchanges

MOA Memorandum of Agreement

MOU Memorandum of Understanding

NA Not Applicable

NARA National Archives and Records Administration

NIST National Institute of Standards and Technology

NPRM Notice of proposed rulemaking

OAGM CMS Office of Acquisition and Grants Management

OCISO Office of the Chief Information Security Officer

OCIO Office of the Chief Information Officer

OMB Office of Management and Budget

OpDiv Operating Division

PHI Protected Health Information

PIA Privacy Impact Assessment

PII Personally Identifiable Information

POC Point of contact

PRA Paperwork Reduction Act

Pub. L. Public Law

RMH Risk Management Handbook

ROCIS Regulatory Information Service Center and Office of Information and Regulatory Affairs Combined Information System

SOR System of Records

SORN System of Records Notice

SP Special Publication

TPWA Third-Party Websites and Applications Privacy Impact Assessment

TRB Technical Review Board

UID Universal Identifier

U.S.C. United States Code



Acronym Definition

XLC eXpedited Life Cycle



Appendix B GlossarySelected terms in this document are defined below.

Terms Definitions

Agreements and/or Sharing Agreements

Where appropriate when sharing personally identifiable information (PII), the organization enters into Memoranda of Understanding, Memoranda of Agreement, Letters of Intent, Computer Matching Agreements, or similar agreements with third-parties that describe the PII covered and enumerate the purposes for which the PII may be used.

Acceptable Risk Safeguards (ARS)

Provides guidance to CMS and its contractors about the minimum acceptable level of required security controls (i.e., the minimum security and privacy control baselines, collectively known as the CMS Minimum Security Requirement baselines) that should be implemented by CMS and CMS contractors to protect CMS’s information and information systems, including CMS Sensitive Information. The ARS provides guidance on customizing (tailoring) controls and enhancements for specific types of missions/business functions, technologies, or environments of operation. Users of the ARS may tailor specific, mandatory controls as well as most of the non-mandatory and unselected controls.

Authority The legal authority (e.g., Statute, Executive Order) that permits the collection, use, maintenance, and sharing of PII both generally and in support of specific programs and the needs of information systems.

Business Owner For the purpose of this document, the person who often is responsible for identifying the need for privacy-related agreements, notices, or other compliance documents is the Business Owner.In general, the Business Owner is the entity or entities responsible for defining, promoting, endorsing, and upholding the business needs and user requirements for the system and for performing user acceptance testing of the final product(s) based on those business needs and user requirements.The Business Owner defines and validates system functionality, access rights, business rules, and the privacy classification, timeliness, completeness, and accuracy of data.The Business Owner is responsible for the overall procurement, development, integration, modification, and operation and maintenance of an information system.

Business Process As used in this document, a method, procedure, process, or rule employed or followed by an organization in the pursuit of its objectives.

Centers for Medicare & Medicaid Services (CMS)

CMS covers 100 million people through Medicare, Medicaid, the Children's Health Insurance Program, and the Health Insurance Marketplace.



Terms DefinitionsChief Information Officer (CIO)

For the purposes of this document, the CIO holds the role of “Program Executive” as that term is used in this document.In general, the CIO is the agency official responsible for: Providing advice and other assistance to the head of the

executive agency and other senior management personnel of the agency to ensure that information technology (IT) is acquired and information resources are managed in a manner that is consistent with laws, executive orders, directives, policies, regulations, and priorities established by the head of the agency

Developing, maintaining, and facilitating the implementation of a sound and integrated IT architecture for the agency

Promoting the effective and efficient design and operation of all major information resources management processes for the agency, including improvements to work processes of the agency

Chief Information Security Officer (CISO)

The CISO should be an agency official (federal government employee) and should fulfill all the responsibilities identified in the HHS IS2P Appendix A Section 11, OpDiv CISOs. The CISO carries out the CIO’s information security responsibilities under federal requirements in conjunction with the Senior Official for Privacy.

CMS FISMA Controls Tracking System (CFACTS)

CMS database that maintains current Federal Information Security Modernization Act (FISMA) information (e.g., points of contact, artifacts) to support organizational requirements and processes (e.g., communication, contingency planning, training, data calls).

Computer Matching Agreement (CMA)

An agreement that an organization enters into in connection with a computer matching program to which the organization is a party. A CMA is required for any computerized comparison of two or more systems of records or a system of records of nonfederal records for: (1) establishing or verifying eligibility or compliance with law and regulations of applicants or recipients/beneficiaries; or (2) recouping payments or overpayments. One purpose of such a program is to establish or verify the eligibility of, or continuing compliance with, statutory and regulatory requirements by, applicants for, recipients or beneficiaries of, participants in, or providers of services with respect to cash or in-kind assistance or payments under federal benefit programs.

Contracting Officer (CO) A person with the authority to enter into, administer, and/or terminate contracts and make related determinations and findings.

Contracting Officer’s Representative (COR)

An individual to whom the CO delegates certain contract administration responsibilities, usually related to technical direction and acceptance issues.

Contractor Nonfederal personnel who perform services for the federal government under the terms and conditions of a contractual agreement. Contractors need security training commensurate with their responsibilities for performing work under the terms and conditions of their contractual agreements.

Cyber Risk Advisor (CRA)

Acts as a subject matter expert in all areas of the CMS Risk Management Framework (RMF).



Terms DefinitionsData Guardian The Data Guardian should be an agency official (federal government

employee) and should fulfill shared responsibilities with the CMS Business Owner identified in the HHS IS2P (“Data Owner/Business Owner”). The responsibilities may require the Data Guardian to: Coordinate with the ISO, Business Owner, Project Manager,

CRA, Privacy Advisor, and/or ISSO to identify the types of information processed and provide information concerning the system and the PII/PHI it contains

Coordinate with COs, CORs, Program/Project Managers, the CISO, ISO, and the Senior Official for Privacy to incorporate appropriate information security and privacy contracting language from relevant sources into each IT contract document

Ensure transparency by providing the public with notices about what CMS does with beneficiary and other personal information

Data Integrity Board (DIB)

An agency’s DIB oversees organizational Computer Matching Agreements to ensure that those agreements comply with the computer matching provisions of the Privacy Act of 1974 (Privacy Act).

Data Use Agreement The Data Use Agreement (DUA) tracks disclosures of PII/PHI to third parties to ensure that any transaction of data is compliant with the Privacy Act of 1974 and the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule. The DUA can involve third-party entities, such as oversight agencies, federal agencies, state agencies, and research institutions.

Department of Health and Human Services (HHS)

The HHS is a cabinet-level department of the federal government with the goal of protecting the health of all Americans and providing essential human services.

Disclosure Activities involving sharing of PII in support of business operations. While “disclosures” may be internal or external (to a third-party organization), for the purposes of the Privacy Handbook, the “Trigger Questions” assume that any “disclosure” is to a third-party organization. Under the Privacy Act, disclosures should be consistent with authorized purposes and documented in public notices.

E-Government Act The e-Government Act of 2002 requires that agencies evaluate systems that collect PII and determine whether the privacy of that PII is adequately protected. Agencies perform this valuation through a PIA. HHS policy states that OpDivs are responsible for completing and maintaining PIAs on all systems (developmental and operational). Upon completion of each assessment, agencies are required to make that PIA publicly available.

Executive Orders A directive issued by the President of the United States that manages operations of the federal government and has the force of law.

eXpedited Life Cycle (XLC)

CMS-XLC-1: The CISO should integrate information security and privacy into the CMS lifecycle processes. The XLC provides the processes and practices of the CMS system development lifecycle in accordance with the CMS Policy for IT Investment Management & Governance. The CMS CISO maintains the RMH Volume 1 Chapter 1, Risk Management, in the XLC to document the CMS information system lifecycle, in accordance with the RMF.



Terms DefinitionsFederal Partner Any federal agency performing specific functions or partnering with

CMS in support of the CMS mission such as executing data-sharing agreements.

Health Insurance Portability and Accountability Act of 1996 (HIPAA)

An act that amended the Internal Revenue Code of 1986 to improve portability and continuity of health insurance coverage in the group and individual markets; to combat waste, fraud, and abuse in health insurance and healthcare delivery; to promote the use of medical savings accounts; to improve access to long-term care services and coverage; to simplify the administration of health insurance; and for other purposes.

Information Exchange Agreement (IEA)

Establishes the terms, conditions, safeguards, and procedures under which the organization is willing (upon request and subject to the provisions of the Agreement and applicable law) to disclose PII and PHI. Can be limited by the “minimum necessary” principles of the HIPAA Privacy Rule.

Information Security and Privacy Group (ISPG)

Leads the development of CMS-specific privacy policy and guidance.

Information System Owner (ISO)

The official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system.

Information System Security Officer (ISSO)

The person responsible for ensuring the security of an information system throughout its lifecycle, from design through disposal. ISSO is synonymous with System Security Officer.The individual assigned responsibility by the Senior Agency Information Security Officer, Authorizing Official, management official, or ISO for maintaining the appropriate operational security posture for an information system or program.

Information Systems Security and Privacy Policy

See [CMS] Information System Security and Privacy Policy OR [HHS] Information System Security and Privacy Policy.

[HHS] Information System Security and Privacy Policy (IS2P)

Provides direction to the IT security programs of OpDivs and Staff Divisions for the security and privacy of HHS data in accordance with FISMA.

[CMS] Information System Security and Privacy Policy (IS2P2)

As required under FISMA, the IS2P2 defines the framework under which CMS protects and controls access to CMS information and information systems. The IS2P2 provides direction to all CMS employees, contractors, and any individual who receive authorization to access CMS IT systems or systems maintained on behalf of CMS to assure the confidentiality, integrity, and availability of CMS information and systems.

Inter-Agency Agreement (IAA)

A written contract in which the federal agency agrees to provide to, purchase from, or exchange services (including data), supplies, or equipment with another federal agency. Inter-agency agreements are between at least one component of HHS and another federal agency and component thereof.



Terms DefinitionsInformation Technology (IT)

Any equipment or interconnected system or subsystem of equipment, used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency. Also, if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency that requires the use of that equipment; or of that equipment to a significant extent in the performance of a service or the furnishing of a product; includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including support services), and related resources; but does not include any equipment acquired by a federal contractor incidental to a federal contract. Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency. For purposes of the preceding sentence, equipment is used by an executive agency if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency that: (i) requires the use of such equipment; or (ii) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term information technology includes computers, ancillary equipment, software, firmware, and similar procedures, services (including support services), and related resources.

Interconnection Security Agreement (ISA)

1. An agreement established between systems that share data and are owned or operated by different organizations. An ISA is required when the system interconnection/information sharing is between a CMS system and a system located external to the CMS secure network infrastructure.

2. An agreement established between the organizations that own and operate connected IT systems to document the technical requirements of the interconnection. The ISA also supports an MOU/MOA between the organizations.

JIRA A project management tool, in use by CMS, that allows users to track issues and bugs related to software.



Terms DefinitionsMatching Program A matching program is:

Any computerized comparison of two or more automated systems of records or a system of records with non-federal records

Used to establish or verify the eligibility of, or continuing compliance with statutory and regulatory requirements by, applicants for, recipients or beneficiaries of, participants in, or providers of services with respect to, cash or in-kind assistance or payments under federal benefit programs

Used to recoup payments or delinquent debts under such federal benefit programs

A “matching program” may also be a computerized comparison of two or more automated, federal personnel or payroll systems of records or a system of federal personnel or payroll records with non-federal records.A number of exceptions to the definition of “matching program” are provided by the Computer Matching and Privacy Protection Act.

Return to trigger table

Memorandum of Agreement (MOA)

An MOA is similar to an MOU, but it defines the relationship of two or more federal partners that enter into a joint project or collaboration but do not exchange resources. The MOA should indicate how each agency will benefit from the agreement.

Memorandum of Understanding (MOU)

A MOU defines the relationship of two or more federal partners that enter into a joint project or collaboration in which they each contribute their own resources. Federal policy requires agencies to develop ISAs or MOUs for system interconnections. CMS has established a standard that an ISA is used when the system interconnection is between separate, but secure, networks, while an MOU is used for interconnections within the same secure network.

Minimum Acceptable Risk Standards for Exchanges (MARS-E)

Addresses the mandates of the Affordable Care Act (ACA) and applies to all ACA Administering Entities (which means Exchanges or Marketplaces, whether federal or state, state Medicaid agencies, CHIP agencies, or state agencies administering the Basic Health Program.) Presents the security and privacy controls necessary and effective for managing ACA systems, data, and privacy.

Minimum Necessary The principle that, to the extent practicable, individually identifiable health information should only be disclosed to the extent needed to support the purpose of the disclosure.

Notice The Privacy Act provides that individuals receive direct notice that their records will be used in a computer matching activity. In typical benefit matching activities, such notices would be added to application and other benefit forms routinely supplied to the individuals whose records will be matched.

Office of Acquisitions and Grants Management (OAGM)

Serves as the Agency’s Head of the Contracting Activity. Plans, organizes, coordinates and manages the activities required to maintain an agency-wide acquisition program.



Terms DefinitionsOffice of Management and Budget (OMB)

The OMB designated the Department of Homeland Security and the NIST as authorities to provide guidance to federal agencies for implementing information security and privacy laws and regulations, including FISMA, HIPAA, and the Privacy Act.

One-Pager In the Privacy Handbook, One-Pagers are one-page guides that provide users with an overview of each type of document addressed. Users may use these to quickly understand the purpose of each document and why it is necessary, the process that should be used to create the document, and where to go for more information about each document and to get responses to frequently asked questions about each document.

Operating Division (OpDiv)

An OpDiv is a major HHS organization with a Standard Administrative Code assigned by the Secretary, whose primary function is to direct and manage substantive programs or major administrative services of the Department and whose head reports directly to the Secretary.

Personally Identifiable Information (PII)

1. Any information about an individual including, but not limited to, education, financial transactions, medical history, and criminal or employment history, and information that can be used to distinguish or trace an individual’s identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, etc., including any other personal information, which is linked or linkable to an individual.

2. 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, or mother’s maiden name.

Privacy Act of 1974 Defines privacy framework for the privacy to which individuals are entitled when the federal government establishes a PII collection, but that has not been specifically authorized under criteria established by an Executive Order or an Act of Congress.

Privacy Advisor The CMS Privacy Advisor establishes and implements enterprise-wide security and privacy policy and procedures consistent with federal requirements. Privacy Advisors influence the proper planning and management of CMS data and IT systems and work with Business Owners to safeguard CMS information and information systems.

Privacy Impact Assessment (PIA)

An analysis of how information is handled: (i) to ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy; (ii) to determine the risks and effects of collecting, maintaining, and disseminating information in identifiable form in an electronic information system; and (iii) to examine and evaluate protections and alternative processes for handling information to mitigate potential privacy risks.



Terms DefinitionsProgram Executive The responsibilities of the Program Executive include, but are not

limited to: Ensuring that systems and information that are critical to the

Program’s mission receive adequate protection Determining, in coordination with the Data Owner/Business

Owner and System Owner, appropriate security controls and identifying resources to implement those controls

Coordinating system and data security requirements with IT security personnel by adequately delegating system-level security requirements

Project Manager In reference to the content of the Privacy Handbook, the Project Manager may be delegated responsibility for performing the duties of the Business Owner; or Project Managers may be responsible for the notices and agreements concerning PII/PHI if the underlying business process does not involve an IT system and is not the responsibility of a Business Owner. When a Project Manager is responsible for any activity involving PII/PHI, they have the same (or the equivalent) responsibilities as the Business Owner.In general, the CMS Project Manager should be an agency official (federal government employee) and should fulfill all responsibilities identified in the HHS IS2P2 Appendix A, Section 28, Project/Program Manager in coordination with the data guardian (see CMS IS2P2 for detailed responsibilities of the Program/Project Manager).

Protected Health Information (PHI)

Protected health information is individually identifiable health information that is also: Transmitted by electronic media, Maintained in electronic media, or Transmitted or maintained in any other form or medium

Note: PHI excludes individually identifiable health information in employment records held by a covered HIPAA entity in its role as employer.

Purpose A federal agency describes the purpose(s) for which PII is collected, used, maintained, and shared in privacy notices and data sharing agreements. This purpose needs to be consistent with the authority under which an organization maintains a PII collection.

Risk Management Handbook (RMH)

The RMH is a series of procedural chapters located in the CMS Information Security and Privacy Library that address CMS unique implementation of FISMA and the NIST Risk Management Framework (RMF) as prescribed by the CMS IS2P2 – Section 4.1.2 Risk Management Framework (CMS-RMF). References to procedures throughout the RMH chapters indicate the related current CMS standards, requirements, directives, and best practices for an effective implementation of the CMS security program.

Senior Official for Privacy (SOP)

The Senior Official for Privacy should be an agency official (federal government employee) and should fulfill all the responsibilities identified in the HHS IS2P Appendix A Section 15, OpDiv SOP [Senior Official for Privacy]. The Senior Official for Privacy carries out the CIO’s privacy responsibilities under federal requirements in conjunction with the CISO.



Terms DefinitionsStandard Operating Procedure

Set of step-by-step instructions compiled by an organization to help workers carry out complex, routine operations. Standard operating procedures aim to achieve efficiency, quality output, and uniformity of performance, while reducing miscommunication and failure to comply with industry regulations.

System Development Lifecycle

The scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and, ultimately, its disposal.

System of Records A “system of records” is any group of records under the control of CMS 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.

A “record” is:

Any item, collection, or grouping of information about an individual that is maintained by an agency that contains either the person’s name, and/or an identifying number, symbol, or other “identifying particular” assigned to the individual, such as a finger or voice print or a photograph

Information may concern (for example) information about the individual’s education, financial transactions, medical history, and criminal or employment history

System of Records Notice

A statement that provides public notice of the existence and character of a System of 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.

Template The template provides an example document that includes required information and often contains annotations to advise the user on how to customize the document to address a specific IT system or business process.

Third-Party Website or Application (TPWA)

OMB Memorandum 10-23, Guidance for Agency Use of TPWAs, allows agencies to use TPWAs to engage openly with the public. Agencies should comply with the requirements in this memorandum to ensure that privacy is fully protected.

OMB Memorandum 10-23 requires that agencies assess their uses of TPWAs to ensure that the uses protect privacy. The mechanism by which agencies perform this assessment is a PIA. In accordance with HHS policy, OpDivs are responsible for completing and maintaining PIAs on all TPWA in use. Upon completion of each assessment, agencies are required to make the PIAs publicly available.



Terms DefinitionsUser For the purposes of the Privacy Handbook, “user” refers to the

Business Owner, Project Manager, or other individual who uses the Handbook to understand compliance processes or conduct the activities described.

In other contexts, policy relevant to CMS may define “user” in other ways, including:

1. Individual or (system) process authorized to access an information system.

2. Any organizational or programmatic entity that uses or receives service from an [automated information system] facility. A user may be either internal or external to the agency organization responsible for the facility, but normally does not report to either the manager or director of the facility or to the same immediate supervisor.

3. The person who uses a computer system and its application programs to perform tasks and produce results.

Website Owner/Administrator

Individual(s) responsible for all aspects of keeping website content and design fresh, backed up, secure, and fully functional.



Appendix C Applicable Laws and GuidanceThis Appendix provides references to both authoritative and guidance documentation supporting the Privacy Handbook. The subsections are organized by level of authority (e.g., statutes take precedence over federal directives and policies).

C.1 Statutes

1The Computer Matching and Privacy Protection Act of 1988 (5 U.S.C. 552a(o) et seq.)

https://www.law.cornell.edu/uscode/text/5/552a

2Federal Information Security Modernization Act (FISMA) of 2014

https://www.congress.gov/bill/113th-congress/senate-bill/2521

3Health Insurance Portability and Accountability Act of 1996 (HIPAA)http://www.hhs.gov/hipaa/

4The Privacy Act of 1974, as amended (5 U.S.C. 552a)https://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-and-Systems/Privacy/PrivacyActof1974.html

5E-Government Act of 2002 (Pub. L. No. 107-347) § 208 https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/content-detail.html

C.2 Federal Directives and Policies

1 FedRAMP Rev. 4 Baselinehttps://www.fedramp.gov/files/2015/03/FedRAMP-Control-Quick-Guide-Rev4-FINAL-01052015.pdf

C.3 OMB Policy and Memoranda

1 OMB Circular A-108, Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A108/omb_circular_a-108.pdf

2 OMB Circular A-130, Management of Federal Information Resourceshttp://www.whitehouse.gov/omb/circulars_a130_a130trans4/


http://www.whitehouse.gov/omb/circulars_a130_a130trans4/

https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A108/omb_circular_a-108.pdf

https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A108/omb_circular_a-108.pdf

https://www.fedramp.gov/files/2015/03/FedRAMP-Control-Quick-Guide-Rev4-FINAL-01052015.pdf

https://www.fedramp.gov/files/2015/03/FedRAMP-Control-Quick-Guide-Rev4-FINAL-01052015.pdf

https://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-and-Systems/Privacy/PrivacyActof1974.html

https://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-and-Systems/Privacy/PrivacyActof1974.html

http://www.hhs.gov/hipaa/

https://www.congress.gov/bill/113th-congress/senate-bill/2521

https://www.law.cornell.edu/uscode/text/5/552a


3 OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 (OMB Memorandum M-03-22)http://www.whitehouse.gov/omb/memoranda_m03-22/

4 OMB M-07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Informationhttps://www.whitehouse.gov/sites/default/files/omb/memoranda/fy2007/m07-16.pdf

C.4 NIST Guidance and Federal Information Processing Standards

1 FIPS-199, Standards for Security Categorization of Federal Information and Information Systemshttp://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

2 NIST SP 800-18, Guide for Developing Security Plans for Federal Information Systems.http://csrc.nist.gov/publications/nistpubs/800-18-Rev1/sp800-18-Rev1-final.pdf

3 NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systemshttp://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

4 NIST SP 800-53-r4, Security and Privacy Controls for Federal Information Systems

and Organizations http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

5 NIST SP 800 53Ar4, Guide for Assessing the Security Controls in Federal Information Systemshttp://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf

6 NIST SP 800-61 Revision 1, Computer Security Incident Handling Guide, dated March 2008http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

7 NIST SP 800-70 r3, National Checklist Program for IT Products — Guidelines for Check list Users and Developershttp://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-70r3.pdf

8 NIST SP 800-171 Rev. 1, Protecting Controlled Unclassified Information (CUI) in Nonfederal Systems and Organizationshttps://csrc.nist.gov/publications/detail/sp/800-171/rev-1/final


https://csrc.nist.gov/publications/detail/sp/800-171/rev-1/final

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-70r3.pdf


http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf


http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

http://csrc.nist.gov/publications/nistpubs/800-18-Rev1/sp800-18-Rev1-final.pdf

http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

https://www.whitehouse.gov/sites/default/files/omb/memoranda/fy2007/m07-16.pdf

http://www.whitehouse.gov/omb/memoranda_m03-22/


9 NIST SP 800-171A, Assessing Security Requirements for Controlled Unclassified Informationhttps://csrc.nist.gov/publications/detail/sp/800-171a/final

C.5 HHS Policy

1 HHS-OCIO-2013-0004 HHS Policy for Personal Use of Information Technology Resourceshttp://www.hhs.gov/ocio/policy/pol-pers-use-it-resources.html (Intranet Only)

2 HHS-OCIO-2014-0001 HHS Information System Security and Privacy Policy (HHS IS2P)HHS Information Security and Privacy Policy (IS2P) – 2014 Edition. If you are having a problem obtaining a copy of this document, please email [email protected]

3 HHS-OCIO 2013-0003S HHS Rules of Behavior for Use of HHS Information Resourceshttp://www.hhs.gov/ocio/policy/hhs-rob.html (Intranet Only)

4 HHS The Office of the Assistant Secretary for Financial Resources (ASFR)http://www.hhs.gov/about/agencies/asfr/ (Intranet Only)

5 HHS Office of Grants and Acquisition Policy and Accountability (OGAPA)http://www.hhs.gov/about/agencies/asfr/ogapa/

6 HHS-OCIO-2008-0001.003 HHS Policy for Responding to Breaches of Personally Identifiable Informationhttp://www.hhs.gov/ocio/policy/20080001.003.html

7 HHS-CSIRT Policy for Information Technology (IT) Security and Privacy Incident Reporting and Responsehttp://www.hhs.gov/ocio/policy/hhs_ocio_policy_2010_0004.html

C.6 CMS Policy and Directives

1 CMS Acceptable Risk Safeguards (ARS), Version 3.1https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/ARS-31-Publication.zip

2 CMS Information Systems Security and Privacy Policy (IS2P2)https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/


https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/IS2P2.pdf

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/ARS-31-Publication.zip

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/ARS-31-Publication.zip

http://www.hhs.gov/ocio/policy/hhs_ocio_policy_2010_0004.html

http://www.hhs.gov/ocio/policy/20080001.003.html

http://www.hhs.gov/about/agencies/asfr/ogapa/

http://www.hhs.gov/about/agencies/asfr/

http://www.hhs.gov/ocio/policy/hhs-rob.html

http://www.hhs.gov/ocio/policy/pol-pers-use-it-resources.html

https://csrc.nist.gov/publications/detail/sp/800-171a/final


InformationSecurity/Downloads/IS2P2.pdf

3 CMS Office of Acquisition and Grants Management (OAGM)

https://www.cms.gov/About-CMS/Leadership/oagm

4 RMH, Chapter 12, Security and Privacy Planning

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/RMH-Chapter-12-Security-and-Privacy-Planning.pdf

5 RMH CMS Information Security (IS) Authorization To Operate Package Guidehttps://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/ATO_Package_Guide.pdf

6 RMH Risk Management Handbook Volume III Standard 6.2 Plan of Action and Milestones Process Guidehttps://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/RMH_VIII_6-2_Plan_of_Action_and_Milestones_Process_Guide.pdf

C.7 Associated CMS Resources

1 CMS Information Security and Privacy Overview Website

https://www.cms.gov/CCIIO/Resources/Regulations-and-Guidance/Downloads/3-MARS-E-v2-0-Catalog-of-Security-and-Privacy-Controls-11102015.pdf

2 CMS Policy for Acceptable Use of CMS Desktop/Laptop and Other IT Resourceshttps://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/Policy-CMS-Policy-for-the-Acceptable-Use-of-CMS-Desktop-Laptop-and-Other-IT-Resources.html

3 CMS Privacy Policy and Governance website


4 MARS-E Document Suite, Version 2.0, Volume III: Catalog of Minimum Acceptable Risk Security and Privacy Controls for Exchanges, November 2015







https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/CIO-IT-Policy-Library-Items/Policy-CMS-Policy-for-the-Acceptable-Use-of-CMS-Desktop-Laptop-and-Other-IT-Resources.html





https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/RMH_VIII_6-2_Plan_of_Action_and_Milestones_Process_Guide.pdf



https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/ATO_Package_Guide.pdf

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/ATO_Package_Guide.pdf







Appendix D SORN Template

(Double Click Image Below to Expand)


OCISOBilling Code: ###-##

Department of Health and Human Services

Privacy Act of 1974; System of Records

AGENCY: DEPARTMENT, AGENCY

ACTION: Notice of a [New/Modified] System of Records.

SUMMARY: The Department of Health and Human Services (HHS),

Centers for Medicare & Medicaid Services (CMS), proposes [develop a

new/modify an existing] system of records subject to the Privacy Act,

System No. ########, titled “[system name].” [Insert a plain-language

description of the system – limit to 1 paragraph if possible].

DATES: New and revised routine uses and new and revised exemptions are

the only parts of a SORN that can't be made effective "upon publication" of

the SORN. Use this wording in the DATES section if neither publishing new

or revised routine uses nor promulgating new or revised exemptions: "In

accordance with 5 USC 552a(e)(4), this notice is applicable [INSERT DATE

OF PUBLICATION IN THE FEDERAL REGISTER]." Use this wording if

publishing new or revised routine uses but not promulgating exemptions: "In


Appendix E CMA Federal Register Publication Template



(Double Click Image Below to Expand)


Billing Code: ####-##

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Privacy Act of 1974; Matching Program

AGENCY: Centers for Medicare & Medicaid Services (CMS), Department of Health and

Human Services (HHS)

ACTION: Notice of NEW/MODIFIED Matching Program.

SUMMARY: In accordance with subsection (e)(12) of the Privacy Act of 1974, as amended,

the Department of Health and Human Services (HHS), Centers for Medicare & Medicaid

Services (CMS) is providing notice of a NEW/MODIFIED computer matching program

between CMS and the FEDERAL PARTNER, “TITLE OF MATCHING AGREEMENT

The matching program provides CMS with FEDERAL PARTNER… EXPLANATION OF

DATA ELEMENTS THAT ARE BEING TRANSMITTED for: (1) REASON FOR

MATCHING PROGRAM; (2) REASON FOR MATCHING PROGRAM; (3) REASON FOR

MATCHING PROGRAM; and (4) REASON FOR MATCHING PROGRAM.

DATES: The deadline for comments on this notice is [INSERT DATE 30 DAYS AFTER

PUBLICATION IN THE FEDERAL REGISTER]. The re-established matching program will


Appendix F CMA Letter to House Committee Template(Double Click Image Below to Expand)

DEPARTMENT OF HEALTH & HUMAN SERVICES Office of the Secretary

Assistant Secretary for Public AffairsWashington, D.C. 20201

MONTH DAY, YEAR

The Honorable Trey Gowdy [ALWAYS CONFIRM THAT THE POINT OF CONTACT HAS NOT CHANGED]Chairman, Committee on Oversight and Government ReformU.S. House of Representatives2157 Rayburn House Office BuildingWashington, D.C. 20515

Dear Mr. Chairman:

In accordance with the reporting requirements of the Privacy Act of 1974, as amended (5 U.S.C. § 552a(r)), the Department of Health and Human Services (HHS), Centers for Medicare and Medicaid Services (CMS) is publishing notice of a NEW/RENEWAL of the TITLE OF MATCHING PROGRAM matching program between the PARTNER and CMS’ BUSINESS COMPONENT. The matching program will enable CMS to INCLUDE A SUMMARY DESCRIPTION OF THE BUSINESS PROCESSES THAT THE MATCHING PROGRAM SUPPORTS.

The proposed matching program was approved by HHS’ Data Integrity Board in MONTH, YEAR, and fully complies with the Privacy Act and OMB Policies. I am transmitting the following to you, prepared in accordance with Office of Management and Budget Circular A-108, titled “Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act”:

1. Narrative Statement2. Federal Register Notice of a Matching Program3. Matching Agreement between FEDERAL PARTNER



Appendix G CMA Letter to Senate Template(Double Click Image Below to Expand)



Month Day, Year

The Honorable Ronald H. Johnson [ALWAYS CONFIRM THAT THE POINT OF CONTACT HAS NOT CHANGED]

Chairman, Committee on Homeland Security and Governmental AffairsUnited States Senate340 Dirksen Senate Office BuildingWashington, D.C. 20510

Dear Mr. Chairman:

In accordance with the reporting requirements of the Privacy Act of1974, as amended (5 U.S.C. § 552a(r)), The Department of Health and Human Services (HHS), Centers for Medicare and Medicaid Services (CMS) is publishing notice of a NEW/RENEWALTITLE OF MATCHING PROGRAM matching program between the FEDERAL PARTNER and CMS’ BUSINESS COMPONENTThe matching program will enable CMS to INCLUDE A SUMMARY DESCRIPTION OF THE BUSINESS PROCESSES THAT THE MATCHING PROGRAM SUPPORTS.

The proposed matching program was approved by HHS’ Data Integrity Board in MONTH, YEAR, and fully complies with the Privacy Act and OMB Policies. I am transmitting the following to you, prepared in accordance with Office of Management and Budget Circular A-108, titled “Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act”:

1. Narrative Statement



Appendix H CMA Letter to OMB Template(Double Click Image Below to Expand)



MONTH DAY, YEAR

Ms. Neomi Rao [ALWAYS CONFIRM THAT THE POINT OF CONTACT HAS NOT CHANGED]

Administrator, Office of Information and Regulatory AffairsOffice of Management and Budget725 17th Street, N.W., Room 262Washington, D.C. 20503

Dear Ms. Rao

In accordance with the reporting requirements of the Privacy Act of 1974, as amended (5 U.S.C. The Department of Health and Human Services (HHS), Centers for Medicare and Medicaid Services (CMS) is publishing notice of a NEW/RENEWAL of the OF MATCHING PROGRAM matching program between the FEDERAL PARTNER and CMS’ BUSINESS COMPONENT. The matching program willenable CMS to INCLUDE A SUMMARY DESCRIPTION OF THE BUSINESS PROCESSES THAT THE MATCHING PROGRAM SUPPORTS

The proposed matching program was approved by HHS’Data Integrity Board in MONTH, YEAR, and fully complies with the Privacy Act and OMB Policies. I am



Appendix I CMA Narrative Statement Template (Double Click Image Below to Expand)



Appendix J IEA Template(Double Click Image Below to Expand)



Appendix K ISA Template(Double Click Image Below to Expand)


CMS SENSITIVE INFORMATION - REQUIRES SPECIAL HANDLING

CENTERS FOR MEDICARE & MEDICAID SERVICES (CMS)

Office of Information Technology (OIT) Information Security and Privacy Group (ISPG)

7500 Security Blvd Baltimore, MD 21244-1850

CMS INTERCONNECTION SECURITY AGREEMENT (ISA)

Between

CENTERS FOR MEDICARE & MEDICAID SERVICES (CMS)

And

<Insert Non-CMS Organization Name>

Baltimore, Maryland 21244-1850 N3-13-27 Security Boulevard, Mail Stop 7500

Centers for Medicare & Medicaid Services DEPARTMENT OF HEALTH & HUMAN SERVICES


Appendix L TPWA Template (Double Click Image Below to Expand)


Third-Party Website and Application (TPWA)PIA Form

1. OPDIV:

2. TPWA Unique Identifier (UID):

3. Tool(s) covered by this TPWA:

4. Is this a new TPWA?

4a. If an existing TPWA, please provide the reason for revision:

5. Will the use of a third-party Website or application create a new or modify an existing HHS/OPDIV System of Records Notice (SORN) under the Privacy Act? 5a. If yes, indicate the SORN number (or identify plans to put one in place.):

6. Will the use of a third-party Website or application create an information collection subject to OMB clearance under the Paperwork Reduction Act (PRA)? 6a. If yes, indicate the OMB approval number and approval number expiration date (or describe the plans to obtain OMB clearance.) OMB Approval Number: Expiration Date:

7. Does the third-party Website or application contain Federal Records?

8. Point of Contact (POC): POC Title: POC Name: POC Organization: POC Email: POC Phone:

9. Describe the specific purpose for the OPDIV use of the third-party Website or application:


Appendix M Points of Contact CMS Privacy AdvisorsName Compone

ntEmail Phone

CMS Privacy Team Privacy [email protected] 410-786-5357

Feedback from the user community ensures that ISPG guidance is of the greatest possible value. If you have any recommendations for improvements to this document, please email [email protected]. Your feedback will be evaluated for incorporation into future releases of the document.


mailto:[email protected]

DRAFT_CMS_Privacy_Handbook_v5_10122018€¦ · Web viewtypes of information processed, privacy and...

Documents

Transcript of DRAFT_CMS_Privacy_Handbook_v5_10122018€¦ · Web viewtypes of information processed, privacy and...