1 line
No EOL
1.6 MiB
1 line
No EOL
1.6 MiB
<!DOCTYPE html><html lang="en"><head><meta charSet="utf-8"/><meta name="viewport" content="width=device-width, initial-scale=1"/><link rel="preload" as="image" href="/_next/static/media/CyberGeek-logo.8e9bbd2b.svg" fetchPriority="high"/><link rel="stylesheet" href="/_next/static/css/ef46db3751d8e999.css" data-precedence="next"/><link rel="stylesheet" href="/_next/static/css/0759e90f4fecfde7.css" data-precedence="next"/><link rel="preload" as="script" fetchPriority="low" href="/_next/static/chunks/webpack-182b67d00f496f9d.js"/><script src="/_next/static/chunks/fd9d1056-ad09c71b7719f2fb.js" async=""></script><script src="/_next/static/chunks/23-260042deb5df7a88.js" async=""></script><script src="/_next/static/chunks/main-app-6de3c3100b91a0a9.js" async=""></script><script src="/_next/static/chunks/30-49b1c1429d73281d.js" async=""></script><script src="/_next/static/chunks/317-0f87feacc1712b2f.js" async=""></script><script src="/_next/static/chunks/223-bc9ed43510898bbb.js" async=""></script><script src="/_next/static/chunks/app/layout-9fc24027bc047aa2.js" async=""></script><script src="/_next/static/chunks/972-6e520d137ef194fb.js" async=""></script><script src="/_next/static/chunks/app/page-cc829e051925e906.js" async=""></script><script src="/_next/static/chunks/app/template-d264bab5e3061841.js" async=""></script><script src="/_next/static/chunks/e37a0b60-b74be3d42787b18d.js" async=""></script><script src="/_next/static/chunks/904-dbddf7494c3e6975.js" async=""></script><script src="/_next/static/chunks/549-c87c1c3bbacc319f.js" async=""></script><script src="/_next/static/chunks/app/learn/%5Bslug%5D/page-5b91cdc45a95ebbe.js" async=""></script><link rel="preload" href="/assets/javascript/uswds-init.min.js" as="script"/><link rel="preload" href="/assets/javascript/uswds.min.js" as="script"/><title>CMS Security and Privacy Handbooks | CMS Information Security & Privacy Group</title><meta name="description" content="Procedures to help CMS staff and contractors implement federal policies and standards for information security and privacy"/><link rel="canonical" href="https://security.cms.gov/learn/cms-security-and-privacy-handbooks"/><meta name="google-site-verification" content="GMZIwBDJgz_o_JYUB2GpJazkrs7P85BaWDsoCjxF32M"/><meta property="og:title" content="CMS Security and Privacy Handbooks | CMS Information Security & Privacy Group"/><meta property="og:description" content="Procedures to help CMS staff and contractors implement federal policies and standards for information security and privacy"/><meta property="og:url" content="https://security.cms.gov/learn/cms-security-and-privacy-handbooks"/><meta property="og:image:type" content="image/jpeg"/><meta property="og:image:width" content="1200"/><meta property="og:image:height" content="630"/><meta property="og:image" content="https://security.cms.gov/learn/cms-security-and-privacy-handbooks/opengraph-image.jpg?d21225707c5ed280"/><meta property="og:type" content="website"/><meta name="twitter:card" content="summary_large_image"/><meta name="twitter:title" content="CMS Security and Privacy Handbooks | CMS Information Security & Privacy Group"/><meta name="twitter:description" content="Procedures to help CMS staff and contractors implement federal policies and standards for information security and privacy"/><meta name="twitter:image:type" content="image/jpeg"/><meta name="twitter:image:width" content="1200"/><meta name="twitter:image:height" content="630"/><meta name="twitter:image" content="https://security.cms.gov/learn/cms-security-and-privacy-handbooks/opengraph-image.jpg?d21225707c5ed280"/><link rel="icon" href="/favicon.ico" type="image/x-icon" sizes="48x48"/><script>(self.__next_s=self.__next_s||[]).push(["/assets/javascript/uswds-init.min.js",{}])</script><script src="/_next/static/chunks/polyfills-78c92fac7aa8fdd8.js" noModule=""></script></head><body><a class="usa-skipnav" href="#main">Skip to main content</a><section class="usa-banner" aria-label="Official website of the United States government"><div class="usa-accordion"><header class="usa-banner__header"><div class="usa-banner__inner"><div class="grid-col-auto"><img aria-hidden="true" alt="" loading="lazy" width="16" height="11" decoding="async" data-nimg="1" class="usa-banner__header-flag" style="color:transparent" srcSet="/_next/image?url=%2Fassets%2Fimg%2Fus_flag_small.png&w=16&q=75 1x, /_next/image?url=%2Fassets%2Fimg%2Fus_flag_small.png&w=32&q=75 2x" src="/_next/image?url=%2Fassets%2Fimg%2Fus_flag_small.png&w=32&q=75"/></div><div class="grid-col-fill tablet:grid-col-auto" aria-hidden="true"><p class="usa-banner__header-text">An official website of the United States government</p><p class="usa-banner__header-action">Here's how you know</p></div><button type="button" class="usa-accordion__button usa-banner__button" aria-expanded="false" aria-controls="gov-banner-default-default"><span class="usa-banner__button-text">Here's how you know</span></button></div></header><div class="usa-banner__content usa-accordion__content" id="gov-banner-default-default" hidden=""><div class="grid-row grid-gap-lg"><div class="usa-banner__guidance tablet:grid-col-6"><img role="img" alt="" aria-hidden="true" loading="lazy" width="40" height="40" decoding="async" data-nimg="1" class="usa-banner__icon usa-media-block__img" style="color:transparent" src="/_next/static/media/icon-dot-gov.3e9cb1b5.svg"/><div class="usa-media-block__body"><p><strong>Official websites use .gov</strong><br/>A <strong>.gov</strong> website belongs to an official government organization in the United States.</p></div></div><div class="usa-banner__guidance tablet:grid-col-6"><img role="img" alt="" aria-hidden="true" loading="lazy" width="40" height="40" decoding="async" data-nimg="1" class="usa-banner__icon usa-media-block__img" style="color:transparent" src="/_next/static/media/icon-https.e7f1a222.svg"/><div class="usa-media-block__body"><p><strong>Secure .gov websites use HTTPS</strong><br/>A <strong>lock</strong> (<span class="icon-lock"><svg xmlns="http://www.w3.org/2000/svg" width="52" height="64" viewBox="0 0 52 64" class="usa-banner__lock-image" role="img" aria-labelledby="banner-lock-description-default" focusable="false"><title id="banner-lock-title-default">Lock</title><desc id="banner-lock-description-default">Locked padlock icon</desc><path fill="#000000" fill-rule="evenodd" d="M26 0c10.493 0 19 8.507 19 19v9h3a4 4 0 0 1 4 4v28a4 4 0 0 1-4 4H4a4 4 0 0 1-4-4V32a4 4 0 0 1 4-4h3v-9C7 8.507 15.507 0 26 0zm0 8c-5.979 0-10.843 4.77-10.996 10.712L15 19v9h22v-9c0-6.075-4.925-11-11-11z"></path></svg></span>) or <strong>https://</strong> means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.</p></div></div></div></div></div></section><div class="usa-overlay"></div><header class="usa-header usa-header--extended"><div class="bg-primary-dark"><div class="usa-navbar"><div class="usa-logo padding-y-4 padding-right-3" id="CyberGeek-logo"><a title="CMS CyberGeek Home" href="/"><img alt="CyberGeek logo" fetchPriority="high" width="298" height="35" decoding="async" data-nimg="1" style="color:transparent" src="/_next/static/media/CyberGeek-logo.8e9bbd2b.svg"/></a></div><button aria-label="Open menu" type="button" class="usa-menu-btn" data-cy="menu-button">Menu</button></div></div><nav aria-label="Primary navigation" class="usa-nav padding-0 desktop:width-auto bg-white grid-container float-none"><div class="usa-nav__inner"><button type="button" class="usa-nav__close margin-0"><img alt="Close" loading="lazy" width="24" height="24" decoding="async" data-nimg="1" style="color:transparent" src="/_next/static/media/close.1fafc2aa.svg"/></button><ul class="usa-nav__primary usa-accordion"><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="roles"><span>Roles</span></button><ul id="roles" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Roles</span></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/information-system-security-officer-isso">Information System Security Officer (ISSO)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-information-system-security-officer-isso-handbook"><span>ISSO Handbook</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-information-system-security-officer-isso-handbook#getting-started-for-new-issos"><span>Getting started (for new ISSOs)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/isso-mentorship-program"><span>ISSO Mentorship Program</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-information-system-security-officer-isso-handbook#training"><span>ISSO Training</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/data-guardian">Data Guardian</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/data-guardian-handbook"><span>Data Guardian Handbook</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/cyber-risk-advisor-cra">Cyber Risk Advisor (CRA)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-security-and-privacy-handbooks"><span>CMS Security and Privacy Handbooks</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters"><span>Risk Management Handbook (RMH)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/business-system-owner">Business / System Owner (BO/SO)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cybersecurity-risk-assessment-program-csrap"><span>Cybersecurity and Risk Assessment Program (CSRAP)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-information-exchange-agreement-iea"><span>Information Exchange Agreement (IEA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-computer-matching-agreement-cma"><span>Computer Matching Agreement (CMA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/isso-service"><span>ISSO As A Service</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="compliance-authorization"><span>Compliance & Authorization</span></button><ul id="compliance-authorization" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Compliance & Authorization</span></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/learn/authorization-operate-ato">Authorization to Operate (ATO)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/authorization-operate-ato"><span>About ATO at CMS</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/authorization-operate-ato#types-of-authorizations"><span>Types of authorizations</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/authorization-operate-ato#ato-stakeholders"><span>ATO stakeholders</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/authorization-operate-ato#related-documents-and-resources"><span>ATO tools and resources</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-technical-reference-architecture-tra"><span>CMS Technical Reference Architecture (TRA)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/learn/ongoing-authorization-oa">Ongoing Authorization (OA)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/ongoing-authorization-oa"><span>About OA at CMS</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/ongoing-authorization-oa#is-my-system-eligible-for-oa"><span>OA eligibility requirements</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/continuous-diagnostics-and-mitigation-cdm"><span>Continuous Diagnostics and Mitigation (CDM)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Assessments & Audits</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/penetration-testing-pentesting"><span>Penetration Testing</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cybersecurity-risk-assessment-program-csrap"><span>Cybersecurity Risk Assessment Program (CSRAP)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/privacy-impact-assessment-pia"><span>Privacy Impact Assessment (PIA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/security-impact-analysis-sia"><span>Security Impact Analysis (SIA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/system-audits"><span>System Audits</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="policy-guidance"><span>Policy & Guidance</span></button><ul id="policy-guidance" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Policy & Guidance</span></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/cms-policies-and-guidance">CMS Policies and Guidance</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-acceptable-risk-safeguards-ars"><span>CMS Acceptable Risk Safeguards (ARS)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-information-systems-security-privacy-policy-is2p2"><span>CMS Information Security and Privacy Policy (IS2P2)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-security-and-privacy-handbooks"><span>CMS Security and Privacy Handbooks</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="https://security.cms.gov/learn/cms-risk-management-framework-rmf"><span>CMS Risk Management Framework (RMF)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/email-encryption-requirements-cms"><span>CMS Email Encryption</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/federal-policies-and-guidance">Federal Policies and Guidance</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/national-institute-standards-and-technology-nist"><span>National Institute of Standards and Technology (NIST)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/federal-information-security-modernization-act-fisma"><span>Federal Information Security Modernization Act (FISMA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/fedramp"><span>Federal Risk and Authorization Management Program (FedRAMP)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/zero-trust"><span>Zero Trust</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="system-security"><span>System Security</span></button><ul id="system-security" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">System Security</span></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/application-security">Application Security</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/threat-modeling"><span>Threat Modeling</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/zero-trust"><span>Zero Trust</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-cloud-services"><span>CMS Cloud Services</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/software-bill-materials-sbom"><span>Software Bill of Materials (SBOM)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/security-operations">Security Operations</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir"><span>Incident Response</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-cybersecurity-integration-center-ccic"><span>CMS Cybersecurity Integration Center (CCIC)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/penetration-testing-pentesting"><span>Penetration Testing</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/risk-management-and-reporting">Risk Management and Reporting</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/continuous-diagnostics-and-mitigation-cdm"><span>Continuous Diagnostics and Mitigation (CDM)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cyber-risk-reports"><span>Cyber Risk Reports</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/plan-action-and-milestones-poam"><span>Plan of Action and Milestones (POA&M)</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="privacy"><span>Privacy</span></button><ul id="privacy" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Privacy</span></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Agreements</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-computer-matching-agreement-cma"><span>Computer Matching Agreement (CMA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-information-exchange-agreement-iea"><span>Information Exchange Agreement (IEA)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Privacy Activities</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/breach-response"><span>Breach Response</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/privacy-impact-assessment-pia"><span>Privacy Impact Assessment (PIA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/system-records-notice-sorn"><span>System of Records Notice (SORN)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Privacy Resources</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/ispg/privacy"><span>Privacy at CMS</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-breach-response-handbook"><span>CMS Breach Response Handbook</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/health-insurance-portability-and-accountability-act-1996-hipaa"><span>Health Insurance Portability and Accessibility Act (HIPAA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-privacy-impact-assessment-pia-handbook"><span>CMS Privacy Impact Assessment (PIA) Handbook</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="tools-services"><span>Tools & Services</span></button><ul id="tools-services" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Tools & Services</span></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Reporting & Compliance</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="https://security.cms.gov/learn/isso-service"><span>ISSO As A Service</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-fisma-continuous-tracking-system-cfacts"><span>CFACTS</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cyber-risk-reports"><span>Cyber Risk Reports and Dashboards</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/continuous-diagnostics-and-mitigation-cdm"><span>Continuous Diagnostics and Mitigation (CDM)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">System Security</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/threat-modeling"><span>Threat Modeling</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-cloud-services"><span>CMS Cloud Services</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-cybersecurity-integration-center-ccic"><span>CMS Cybersecurity Integration Center (CCIC)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="https://security.cms.gov/learn/cms-security-data-lake-sdl"><span>CMS Security Data Lake (SDL)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Tests & Assessments</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cybersecurity-risk-assessment-program-csrap"><span>Cybersecurity Risk Assessment Program (CSRAP)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/penetration-testing-pentesting"><span>Penetration Testing</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/privacy-impact-assessment-pia"><span>Privacy Impact Assessment (PIA)</span></a></li></ul></section></div></li></ul></li></ul><div class="usa-nav__secondary padding-left-2"><section aria-label="Header search box"><form class="usa-search usa-search--small" role="search" action="/search"><label class="usa-sr-only" for="header-search-box">Search</label><input class="usa-input search__input" id="header-search-box" type="search" name="ispg[query]"/><button aria-label="header search box button" class="usa-button" id="header-search-box-btn" type="submit"><svg aria-describedby="searchIcon" class="usa-icon" aria-hidden="true" focusable="false" role="img"><title id="searchIcon">Search</title><use href="/assets/img/sprite.svg#search"></use></svg></button></form></section></div></div></nav></header><main id="main"><div id="template"><!--$--><!--/$--><section class="hero hero--theme-explainer undefined"><div class="maxw-widescreen margin-x-auto padding-x-2 desktop:padding-x-0 padding-top-4 padding-bottom-6 desktop:padding-y-7"><div class="tablet:grid-container position-relative "><div class="hero__row grid-row grid-gap"><div class="tablet:grid-col-5 widescreen:position-relative"></div><div class="hero__column tablet:grid-col-7 flow padding-bottom-2"><h1 class="hero__heading margin-0 line-height-sans-3 desktop:line-height-sans-2">CMS Security and Privacy Handbooks</h1><p class="hero__description">Procedures to help CMS staff and contractors implement federal policies and standards for information security and privacy</p><div class="hero__meta radius-lg padding-x-2 padding-y-1 bg-white font-sans-2xs line-height-sans-5 display-inline-block text-primary-darker">Contact: <span class="text-bold">ISPG Policy Team</span><span class="hidden-mobile"> | </span><span class="break-mobile"><a href="mailto:CISO@cms.hhs.gov">CISO@cms.hhs.gov</a></span></div></div><div class="tablet:position-absolute tablet:top-0"><div class="[ flow ] bg-primary-light radius-lg padding-2 text-base-darkest maxw-mobile"><div class="display-flex flex-align-center font-sans-lg margin-bottom-2 text-italic desktop:text-no-wrap"><img alt="slack logo" loading="lazy" width="21" height="21" decoding="async" data-nimg="1" class="display-inline margin-right-1" style="color:transparent" src="/_next/static/media/slackLogo.f5836093.svg"/>CMS Slack Channel</div><ul class="add-list-reset"><li class="line-height-sans-5 margin-top-0">#ispg-sec_privacy-policy</li></ul></div></div></div></div></div></section><div class="grid-container"><div class="grid-row grid-gap margin-top-5"><div class="tablet:grid-col-4"><nav class="table-of-contents overflow-y-auto overflow-x-hidden position-sticky top-3 padding-1 radius-lg shadow-2 display-none tablet:display-block" aria-label="Table of contents"><div class="text-uppercase text-bold border-bottom border-base-lighter padding-bottom-1">Table of Contents</div><p class="text-italic text-base font-sans-xs">No table of content entries to display.</p></nav></div><div class="tablet:grid-col-8 content"><section><div class="text-block text-block--theme-explainer"><h2>What are the CMS Security and Privacy Handbooks?</h2><p>The CMS Security and Privacy Handbooks help CMS staff and contractors to follow federal policies and standards that keep CMS information and systems safe. They provide practical guidance for implementing the requirements of the <a href="/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2">CMS Information Systems Security and Privacy Policy (IS2P2)</a> and the <a href="/policy-guidance/cms-acceptable-risk-safeguards-ars">Acceptable Risk Safeguards (ARS)</a>. </p><h3>What authority do the Handbooks have?</h3><p>CMS has several levels of policy and guidance for the information security and privacy program:</p><p><strong>Policies and standards</strong>, which are enterprise-level directives and the details for how they must be implemented. Our policies and standards are the <a href="https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2">CMS Information System Security and Privacy Policy (IS2P2)</a> and the <a href="https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars">CMS Acceptable Risk Safeguards (ARS)</a>.</p><p><strong>Program plans</strong>, which explain how the high-level security and privacy programs at CMS uphold the policies and standards, laying out a roadmap for all ISPG activities. Our program plans include the <a href="https://security.cms.gov/policy-guidance/cms-privacy-program-plan">Privacy Program Plan</a> and the <a href="https://security.cms.gov/policy-guidance/cms-cyber-risk-management-plan-crmp">CMS Cyber Risk Management Plan (CRMP)</a>.</p><p><strong>Procedural handbooks</strong>, which give practical guidance about how to implement the requirements found within the policies, standards, and program plans. Our procedural handbooks are the <a href="https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks">CMS Security and Privacy Handbooks</a> – a go-to resource for anyone who is involved with the work of keeping CMS systems and data safe.</p><p>The Handbooks are provided as <strong>reliable guidance</strong> approved by the CMS Chief Information Security Officer (CISO), who is responsible for implementing the agency-wide information security program. The Handbooks support the policies and standards that CMS uses to meet requirements from higher-level authorities such as the Department of Health and Human Services (HHS). </p><p>The Handbooks also provide <strong>step-by-step instructions</strong> for CMS security and privacy activities such as <a href="https://security.cms.gov/policy-guidance/cms-privacy-impact-assessment-pia-handbook">Privacy Impact Assessment</a>, <a href="https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap">Cybersecurity and Risk Assessment Program (CSRAP)</a>, <a href="https://security.cms.gov/policy-guidance/threat-modeling-handbook">Threat Modeling</a>, and more.</p><p>These Handbooks do not supersede any applicable laws, existing labor management agreements, or higher-level agency directives or other governance documents. To learn more about the authorities, directives and laws that govern the CMS security and privacy program, see the CMS Information Security and Privacy Policy (IS2P2).</p></div><section class="callout callout--type-explainer [ flow ] font-size-md radius-lg line-height-sans-5"><h1 class="callout__header text-bold font-sans-lg"><svg class="usa-icon" aria-hidden="true" focusable="false" role="img"><use href="/assets/img/sprite.svg#info_outline"></use></svg>See all Security and Privacy Handbooks</h1><p>Using the Search function on the ISPG "CyberGeek" website, you can search and filter to find CMS Security and Privacy Handbooks on a variety of topics.</p><p><a href="https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks">Go to the Handbooks</a></p></section><div class="text-block text-block--theme-explainer"><h2>Risk Management Handbook (RMH) chapters</h2><p>The CMS Risk Management Handbook (RMH) chapters are a series of procedures that support CMS policies and standards, mapped to specific control families in the <a href="/learn/national-institute-standards-and-technology-nist#nist-risk-management-framework-rmf">NIST Risk Management Framework</a>. </p><p>Over time, <strong>the RMH chapters will be modified and absorbed into the broader CMS Security and Privacy Handbooks</strong> for a more flexible approach to procedural guidance – not dependent on specific security controls, but still covering all the topics needed to help CMS staff and contractors follow policies, standards, and best practices.</p><p>Use the links below to access the chapters of the Risk Management Handbook. Note that some chapters may not be listed here, as the RMH is evolving.</p><ul><li>Are you looking for <em>RMH Chapter 1: Access Control</em>? See the new <a href="https://security.cms.gov/policy-guidance/cms-access-control-handbook">CMS Access Control Handbook</a>.<br> </li><li><a href="/policy-guidance/risk-management-handbook-chapter-2-awareness-and-training">RMH Chapter 2: Awareness and Training</a></li><li><a href="/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca">RMH Chapter 4: Assessment and Authorization</a></li><li><a href="/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm">RMH Chapter 5: Configuration Management</a><br> </li><li>Are you looking for <em>RMH Chapter 6: Contingency Planning</em>? See the new <a href="https://security.cms.gov/policy-guidance/cms-information-system-contingency-plan-iscp-handbook">CMS Information System Contingency Plan (ISCP) Handbook</a>.<br> </li><li><a href="/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir">RMH Chapter 8: Incident Response</a></li><li><a href="/policy-guidance/risk-management-handbook-chapter-9-maintenance-ma">RMH Chapter 9: Maintenance</a><br> </li><li>Are you looking for <em>RMH Chapter 10: Media Protection</em>? See the new <a href="https://security.cms.gov/policy-guidance/cms-media-protection-mp-handbook">CMS Media Protection Handbook</a>.<br> </li><li><a href="/policy-guidance/risk-management-handbook-chapter-11-physical-environmental-protection">RMH Chapter 11: Physical and Environmental Protection</a></li><li><a href="/policy-guidance/risk-management-handbook-chapter-12-security-privacy-planning-pl">RMH Chapter 12: Security and Privacy Planning</a></li><li><a href="/policy-guidance/risk-management-handbook-chapter-13-personnel-security-ps">RMH Chapter 13: Personnel Security</a></li><li><a href="/policy-guidance/risk-management-handbook-chapter-14-risk-assessment-ra">RMH Chapter 14: Risk Assessment</a></li><li><a href="/policy-guidance/risk-management-handbook-chapter-15-system-services-acquisition">RMH Chapter 15: System and Services Acquisition</a></li><li><a href="/policy-guidance/risk-management-handbook-chapter-16-system-communications-protection">RMH Chapter 16: System and Communications Protection</a><br> </li><li>Are you looking for <em>RMH Chapter 19: Privacy Procedures</em>? See the new <a href="https://security.cms.gov/policy-guidance/cms-privacy-program-plan">Privacy Program Plan</a> and the <a href="https://security.cms.gov/ispg/privacy">whole collection of Privacy resources</a> here on the ISPG website.</li></ul></div></section></div></div></div><div class="cg-cards grid-container"><h2 class="cg-cards__heading" id="related-documents-and-resources">Related documents and resources</h2><ul aria-label="cards" class="usa-card-group"><li class="usa-card grid-col-12 tablet:grid-col-4"><div class="usa-card__container "><div class="usa-card__header"><h3 class="margin-top-1 line-height-sans-2 text-bold text-base-darkest"><a class="usa-card__link text-no-underline" href="/policy-guidance/cms-access-control-handbook">CMS Access Control Handbook</a></h3></div><div class="usa-card__body font-sans-2xs line-height-sans-4 text-base-darkest"><p>A guide that provides an overview of the policies, procedures, and processes needed to implement security requirements for the Access Control (AC) family</p></div></div></li><li class="usa-card grid-col-12 tablet:grid-col-4"><div class="usa-card__container "><div class="usa-card__header"><h3 class="margin-top-1 line-height-sans-2 text-bold text-base-darkest"><a class="usa-card__link text-no-underline" href="/policy-guidance/cms-privacy-impact-assessment-pia-handbook">CMS Privacy Impact Assessment (PIA) Handbook</a></h3></div><div class="usa-card__body font-sans-2xs line-height-sans-4 text-base-darkest"><p>Information, tips, and tricks for writing your Privacy Impact Assessment (PIA) concisely and correctly</p></div></div></li><li class="usa-card grid-col-12 tablet:grid-col-4"><div class="usa-card__container "><div class="usa-card__header"><h3 class="margin-top-1 line-height-sans-2 text-bold text-base-darkest"><a class="usa-card__link text-no-underline" href="/policy-guidance/cms-breach-response-handbook">CMS Breach Response Handbook</a></h3></div><div class="usa-card__body font-sans-2xs line-height-sans-4 text-base-darkest"><p>Procedures for handling a breach of sensitive data at CMS, including roles, responsibilities, and reporting requirements</p></div></div></li><li class="usa-card grid-col-12 tablet:grid-col-4"><div class="usa-card__container "><div class="usa-card__header"><h3 class="margin-top-1 line-height-sans-2 text-bold text-base-darkest"><a class="usa-card__link text-no-underline" href="/policy-guidance/cms-plan-action-and-milestones-poam-handbook">CMS Plan of Action and Milestones (POA&M) Handbook</a></h3></div><div class="usa-card__body font-sans-2xs line-height-sans-4 text-base-darkest"><p>A complete guide to creating, managing, and closing your system’s POA&M</p></div></div></li><li class="usa-card grid-col-12 tablet:grid-col-4"><div class="usa-card__container "><div class="usa-card__header"><h3 class="margin-top-1 line-height-sans-2 text-bold text-base-darkest"><a class="usa-card__link text-no-underline" href="/policy-guidance/cms-key-management-handbook">CMS Key Management Handbook </a></h3></div><div class="usa-card__body font-sans-2xs line-height-sans-4 text-base-darkest"><p>Guidance on the management lifecycle of cryptographic keys: data used to lock or unlock functions, including authentication, authorization, and encryption </p></div></div></li><li class="usa-card grid-col-12 tablet:grid-col-4"><div class="usa-card__container "><div class="usa-card__header"><h3 class="margin-top-1 line-height-sans-2 text-bold text-base-darkest"><a class="usa-card__link text-no-underline" href="/policy-guidance/cms-information-system-security-officer-isso-handbook">CMS Information System Security Officer (ISSO) Handbook</a></h3></div><div class="usa-card__body font-sans-2xs line-height-sans-4 text-base-darkest"><p>Guidance to help ISSOs in their daily work, including role descriptions, resources, points of contact, and training</p></div></div></li></ul></div></div></main><footer class="usa-footer usa-footer--slim"><div class="grid-container"><div class="grid-row flex-align-end"><div class="grid-col"><div class="usa-footer__return-to-top"><a class="font-sans-xs" href="#">Return to top</a></div></div><div class="grid-col padding-bottom-2 padding-top-4 display-flex flex-justify-end"><a class="usa-button" href="/feedback">Give feedback</a></div></div></div><div class="usa-footer__primary-section"><div class="usa-footer__primary-container grid-row"><div class="tablet:grid-col-3"><a class="usa-footer__primary-link" href="/"><img alt="CyberGeek logo" loading="lazy" width="142" height="26" decoding="async" data-nimg="1" style="color:transparent" src="/_next/static/media/CyberGeek-logo.8e9bbd2b.svg"/></a><p class="usa-footer__logo-heading display-none tablet-lg:display-block">The official website of the CMS Information Security and Privacy Group (ISPG)</p></div><div class="tablet:grid-col-12 tablet-lg:grid-col-9"><nav class="usa-footer__nav" aria-label="Footer navigation,"><ul class="grid-row grid-gap"><li class=" tablet:grid-col-3 desktop:grid-col-auto usa-footer__primary-content "><a class="usa-footer__primary-link" href="/learn/about-ispg-cybergeek">What is CyberGeek?</a></li><li class=" tablet:grid-col-3 desktop:grid-col-auto usa-footer__primary-content "><a class="usa-footer__primary-link" href="https://www.cms.gov/privacy">Privacy policy</a></li><li class=" tablet:grid-col-3 desktop:grid-col-auto usa-footer__primary-content "><a class="usa-footer__primary-link" href="https://www.cms.gov/about-cms/information-systems/privacy/vulnerability-disclosure-policy">CMS Vulnerability Disclosure Policy</a></li><li class=" tablet:grid-col-3 desktop:grid-col-auto usa-footer__primary-content "><a class="usa-footer__primary-link" href="https://www.cms.gov/About-CMS/Agency-Information/Aboutwebsite/Policiesforaccessibility">Accessibility</a></li></ul></nav></div></div></div><div class="usa-footer__secondary-section"><div class="grid-container"><div class="usa-footer__logo grid-row grid-gap-2"><div class="mobile-lg:grid-col-3"><a href="https://www.cms.gov/"><img alt="CMS homepage" loading="lazy" width="124" height="29" decoding="async" data-nimg="1" style="color:transparent" src="/_next/static/media/cmsLogo.10a64ce4.svg"/></a></div><div class="mobile-lg:grid-col-7"><p class="font-sans-3xs line-height-sans-3">A federal government website managed and paid for by the U.S. Centers for Medicare & Medicaid Services.</p><address class="font-sans-3xs line-height-sans-3">7500 Security Boulevard, Baltimore, MD 21244</address></div></div></div></div></footer><script>(self.__next_s=self.__next_s||[]).push(["/assets/javascript/uswds.min.js",{}])</script><script src="/_next/static/chunks/webpack-182b67d00f496f9d.js" async=""></script><script>(self.__next_f=self.__next_f||[]).push([0]);self.__next_f.push([2,null])</script><script>self.__next_f.push([1,"1:HL[\"/_next/static/css/ef46db3751d8e999.css\",\"style\"]\n2:HL[\"/_next/static/css/0759e90f4fecfde7.css\",\"style\"]\n"])</script><script>self.__next_f.push([1,"3:I[5751,[],\"\"]\n6:I[9275,[],\"\"]\n8:I[1343,[],\"\"]\nb:I[6130,[],\"\"]\n7:[\"slug\",\"cms-security-and-privacy-handbooks\",\"d\"]\nc:[]\n0:[\"$\",\"$L3\",null,{\"buildId\":\"m9SaS4P6zugJbBHpXSk5Y\",\"assetPrefix\":\"\",\"urlParts\":[\"\",\"learn\",\"cms-security-and-privacy-handbooks\"],\"initialTree\":[\"\",{\"children\":[\"learn\",{\"children\":[[\"slug\",\"cms-security-and-privacy-handbooks\",\"d\"],{\"children\":[\"__PAGE__\",{}]}]}]},\"$undefined\",\"$undefined\",true],\"initialSeedData\":[\"\",{\"children\":[\"learn\",{\"children\":[[\"slug\",\"cms-security-and-privacy-handbooks\",\"d\"],{\"children\":[\"__PAGE__\",{},[[\"$L4\",\"$L5\",null],null],null]},[null,[\"$\",\"$L6\",null,{\"parallelRouterKey\":\"children\",\"segmentPath\":[\"children\",\"learn\",\"children\",\"$7\",\"children\"],\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L8\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":\"$undefined\",\"notFoundStyles\":\"$undefined\"}]],null]},[null,[\"$\",\"$L6\",null,{\"parallelRouterKey\":\"children\",\"segmentPath\":[\"children\",\"learn\",\"children\"],\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L8\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":\"$undefined\",\"notFoundStyles\":\"$undefined\"}]],null]},[[[[\"$\",\"link\",\"0\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/css/ef46db3751d8e999.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\"}],[\"$\",\"link\",\"1\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/css/0759e90f4fecfde7.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\"}]],\"$L9\"],null],null],\"couldBeIntercepted\":false,\"initialHead\":[null,\"$La\"],\"globalErrorComponent\":\"$b\",\"missingSlots\":\"$Wc\"}]\n"])</script><script>self.__next_f.push([1,"d:I[4080,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"\"]\ne:I[8173,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"972\",\"static/chunks/972-6e520d137ef194fb.js\",\"931\",\"static/chunks/app/page-cc829e051925e906.js\"],\"Image\"]\nf:I[7529,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"default\"]\n11:I[231,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"972\",\"static/chunks/972-6e520d137ef194fb.js\",\"931\",\"static/chunks/app/page-cc829e051925e906.js\"],\"\"]\n12:I[7303,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"default\"]\n13:I[8521,[\"489\",\"static/chunks/app/template-d264bab5e3061841.js\"],\"default\"]\n14:I[5922,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"972\",\"static/chunks/972-6e520d137ef194fb.js\",\"931\",\"static/chunks/app/page-cc829e051925e906.js\"],\"default\"]\n15:I[7182,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"default\"]\n16:I[4180,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"TealiumTagManager\"]\n10:Tdced,"])</script><script>self.__next_f.push([1,"{\"id\":\"mega-menu\",\"linkset\":{\"elements\":[{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Roles\",\"hierarchy\":[\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/information-system-security-officer-isso\",\"attributes\":{\"title\":\"Information System Security Officer (ISSO)\",\"hierarchy\":[\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook\",\"attributes\":{\"title\":\"ISSO Handbook\",\"hierarchy\":[\"0\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#getting-started-for-new-issos\",\"attributes\":{\"title\":\"Getting started (for new ISSOs)\",\"hierarchy\":[\"0\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-mentorship-program\",\"attributes\":{\"title\":\"ISSO Mentorship Program\",\"hierarchy\":[\"0\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#training\",\"attributes\":{\"title\":\"ISSO Training\",\"hierarchy\":[\"0\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/data-guardian\",\"attributes\":{\"title\":\"Data Guardian\",\"hierarchy\":[\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/data-guardian-handbook\",\"attributes\":{\"title\":\"Data Guardian Handbook\",\"hierarchy\":[\"0\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cyber-risk-advisor-cra\",\"attributes\":{\"title\":\"Cyber Risk Advisor (CRA)\",\"hierarchy\":[\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"0\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\",\"attributes\":{\"title\":\"Risk Management Handbook (RMH)\",\"hierarchy\":[\"0\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/business-system-owner\",\"attributes\":{\"title\":\"Business / System Owner (BO/SO)\",\"hierarchy\":[\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity and Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"0\",\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"0\",\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"0\",\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"0\",\"3\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Compliance \u0026 Authorization\",\"hierarchy\":[\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"Authorization to Operate (ATO)\",\"hierarchy\":[\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"About ATO at CMS\",\"hierarchy\":[\"1\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#types-of-authorizations\",\"attributes\":{\"title\":\"Types of authorizations\",\"hierarchy\":[\"1\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#ato-stakeholders\",\"attributes\":{\"title\":\"ATO stakeholders\",\"hierarchy\":[\"1\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#related-documents-and-resources\",\"attributes\":{\"title\":\"ATO tools and resources\",\"hierarchy\":[\"1\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-technical-reference-architecture-tra\",\"attributes\":{\"title\":\"CMS Technical Reference Architecture (TRA)\",\"hierarchy\":[\"1\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"Ongoing Authorization (OA)\",\"hierarchy\":[\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"About OA at CMS\",\"hierarchy\":[\"1\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa#is-my-system-eligible-for-oa\",\"attributes\":{\"title\":\"OA eligibility requirements\",\"hierarchy\":[\"1\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"1\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Assessments \u0026 Audits\",\"hierarchy\":[\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"1\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"1\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"1\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/security-impact-analysis-sia\",\"attributes\":{\"title\":\"Security Impact Analysis (SIA)\",\"hierarchy\":[\"1\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-audits\",\"attributes\":{\"title\":\"System Audits\",\"hierarchy\":[\"1\",\"2\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Policy \u0026 Guidance\",\"hierarchy\":[\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cms-policies-and-guidance\",\"attributes\":{\"title\":\"CMS Policies and Guidance\",\"hierarchy\":[\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-acceptable-risk-safeguards-ars\",\"attributes\":{\"title\":\"CMS Acceptable Risk Safeguards (ARS)\",\"hierarchy\":[\"2\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\",\"attributes\":{\"title\":\"CMS Information Security and Privacy Policy (IS2P2)\",\"hierarchy\":[\"2\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"2\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-risk-management-framework-rmf\",\"attributes\":{\"title\":\"CMS Risk Management Framework (RMF)\",\"hierarchy\":[\"2\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/email-encryption-requirements-cms\",\"attributes\":{\"title\":\"CMS Email Encryption\",\"hierarchy\":[\"2\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/federal-policies-and-guidance\",\"attributes\":{\"title\":\"Federal Policies and Guidance\",\"hierarchy\":[\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/national-institute-standards-and-technology-nist\",\"attributes\":{\"title\":\"National Institute of Standards and Technology (NIST)\",\"hierarchy\":[\"2\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/federal-information-security-modernization-act-fisma\",\"attributes\":{\"title\":\"Federal Information Security Modernization Act (FISMA)\",\"hierarchy\":[\"2\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/fedramp\",\"attributes\":{\"title\":\"Federal Risk and Authorization Management Program (FedRAMP)\",\"hierarchy\":[\"2\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"2\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/application-security\",\"attributes\":{\"title\":\"Application Security\",\"hierarchy\":[\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"3\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"3\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"3\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/software-bill-materials-sbom\",\"attributes\":{\"title\":\"Software Bill of Materials (SBOM)\",\"hierarchy\":[\"3\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/security-operations\",\"attributes\":{\"title\":\"Security Operations\",\"hierarchy\":[\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\",\"attributes\":{\"title\":\"Incident Response\",\"hierarchy\":[\"3\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"3\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"3\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/risk-management-and-reporting\",\"attributes\":{\"title\":\"Risk Management and Reporting\",\"hierarchy\":[\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"3\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports\",\"hierarchy\":[\"3\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/plan-action-and-milestones-poam\",\"attributes\":{\"title\":\"Plan of Action and Milestones (POA\u0026M)\",\"hierarchy\":[\"3\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy\",\"hierarchy\":[\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Agreements\",\"hierarchy\":[\"4\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"4\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"4\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Activities\",\"hierarchy\":[\"4\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/breach-response\",\"attributes\":{\"title\":\"Breach Response\",\"hierarchy\":[\"4\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"4\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-records-notice-sorn\",\"attributes\":{\"title\":\"System of Records Notice (SORN)\",\"hierarchy\":[\"4\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Resources\",\"hierarchy\":[\"4\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/privacy\",\"attributes\":{\"title\":\"Privacy at CMS\",\"hierarchy\":[\"4\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-breach-response-handbook\",\"attributes\":{\"title\":\"CMS Breach Response Handbook\",\"hierarchy\":[\"4\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/health-insurance-portability-and-accountability-act-1996-hipaa\",\"attributes\":{\"title\":\"Health Insurance Portability and Accessibility Act (HIPAA)\",\"hierarchy\":[\"4\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-privacy-impact-assessment-pia-handbook\",\"attributes\":{\"title\":\"CMS Privacy Impact Assessment (PIA) Handbook\",\"hierarchy\":[\"4\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tools \u0026 Services\",\"hierarchy\":[\"5\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Reporting \u0026 Compliance\",\"hierarchy\":[\"5\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"5\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-fisma-continuous-tracking-system-cfacts\",\"attributes\":{\"title\":\"CFACTS\",\"hierarchy\":[\"5\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports and Dashboards\",\"hierarchy\":[\"5\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"5\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"5\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"5\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"5\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"5\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-security-data-lake-sdl\",\"attributes\":{\"title\":\"CMS Security Data Lake (SDL)\",\"hierarchy\":[\"5\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tests \u0026 Assessments\",\"hierarchy\":[\"5\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"5\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"5\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"5\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}}],\"size\":87},\"elements\":[{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Roles\",\"hierarchy\":[\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/information-system-security-officer-isso\",\"attributes\":{\"title\":\"Information System Security Officer (ISSO)\",\"hierarchy\":[\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook\",\"attributes\":{\"title\":\"ISSO Handbook\",\"hierarchy\":[\"0\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#getting-started-for-new-issos\",\"attributes\":{\"title\":\"Getting started (for new ISSOs)\",\"hierarchy\":[\"0\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-mentorship-program\",\"attributes\":{\"title\":\"ISSO Mentorship Program\",\"hierarchy\":[\"0\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#training\",\"attributes\":{\"title\":\"ISSO Training\",\"hierarchy\":[\"0\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/data-guardian\",\"attributes\":{\"title\":\"Data Guardian\",\"hierarchy\":[\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/data-guardian-handbook\",\"attributes\":{\"title\":\"Data Guardian Handbook\",\"hierarchy\":[\"0\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cyber-risk-advisor-cra\",\"attributes\":{\"title\":\"Cyber Risk Advisor (CRA)\",\"hierarchy\":[\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"0\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\",\"attributes\":{\"title\":\"Risk Management Handbook (RMH)\",\"hierarchy\":[\"0\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/business-system-owner\",\"attributes\":{\"title\":\"Business / System Owner (BO/SO)\",\"hierarchy\":[\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity and Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"0\",\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"0\",\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"0\",\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"0\",\"3\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Compliance \u0026 Authorization\",\"hierarchy\":[\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"Authorization to Operate (ATO)\",\"hierarchy\":[\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"About ATO at CMS\",\"hierarchy\":[\"1\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#types-of-authorizations\",\"attributes\":{\"title\":\"Types of authorizations\",\"hierarchy\":[\"1\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#ato-stakeholders\",\"attributes\":{\"title\":\"ATO stakeholders\",\"hierarchy\":[\"1\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#related-documents-and-resources\",\"attributes\":{\"title\":\"ATO tools and resources\",\"hierarchy\":[\"1\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-technical-reference-architecture-tra\",\"attributes\":{\"title\":\"CMS Technical Reference Architecture (TRA)\",\"hierarchy\":[\"1\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"Ongoing Authorization (OA)\",\"hierarchy\":[\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"About OA at CMS\",\"hierarchy\":[\"1\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa#is-my-system-eligible-for-oa\",\"attributes\":{\"title\":\"OA eligibility requirements\",\"hierarchy\":[\"1\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"1\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Assessments \u0026 Audits\",\"hierarchy\":[\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"1\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"1\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"1\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/security-impact-analysis-sia\",\"attributes\":{\"title\":\"Security Impact Analysis (SIA)\",\"hierarchy\":[\"1\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-audits\",\"attributes\":{\"title\":\"System Audits\",\"hierarchy\":[\"1\",\"2\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Policy \u0026 Guidance\",\"hierarchy\":[\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cms-policies-and-guidance\",\"attributes\":{\"title\":\"CMS Policies and Guidance\",\"hierarchy\":[\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-acceptable-risk-safeguards-ars\",\"attributes\":{\"title\":\"CMS Acceptable Risk Safeguards (ARS)\",\"hierarchy\":[\"2\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\",\"attributes\":{\"title\":\"CMS Information Security and Privacy Policy (IS2P2)\",\"hierarchy\":[\"2\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"2\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-risk-management-framework-rmf\",\"attributes\":{\"title\":\"CMS Risk Management Framework (RMF)\",\"hierarchy\":[\"2\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/email-encryption-requirements-cms\",\"attributes\":{\"title\":\"CMS Email Encryption\",\"hierarchy\":[\"2\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/federal-policies-and-guidance\",\"attributes\":{\"title\":\"Federal Policies and Guidance\",\"hierarchy\":[\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/national-institute-standards-and-technology-nist\",\"attributes\":{\"title\":\"National Institute of Standards and Technology (NIST)\",\"hierarchy\":[\"2\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/federal-information-security-modernization-act-fisma\",\"attributes\":{\"title\":\"Federal Information Security Modernization Act (FISMA)\",\"hierarchy\":[\"2\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/fedramp\",\"attributes\":{\"title\":\"Federal Risk and Authorization Management Program (FedRAMP)\",\"hierarchy\":[\"2\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"2\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/application-security\",\"attributes\":{\"title\":\"Application Security\",\"hierarchy\":[\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"3\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"3\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"3\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/software-bill-materials-sbom\",\"attributes\":{\"title\":\"Software Bill of Materials (SBOM)\",\"hierarchy\":[\"3\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/security-operations\",\"attributes\":{\"title\":\"Security Operations\",\"hierarchy\":[\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\",\"attributes\":{\"title\":\"Incident Response\",\"hierarchy\":[\"3\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"3\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"3\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/risk-management-and-reporting\",\"attributes\":{\"title\":\"Risk Management and Reporting\",\"hierarchy\":[\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"3\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports\",\"hierarchy\":[\"3\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/plan-action-and-milestones-poam\",\"attributes\":{\"title\":\"Plan of Action and Milestones (POA\u0026M)\",\"hierarchy\":[\"3\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy\",\"hierarchy\":[\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Agreements\",\"hierarchy\":[\"4\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"4\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"4\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Activities\",\"hierarchy\":[\"4\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/breach-response\",\"attributes\":{\"title\":\"Breach Response\",\"hierarchy\":[\"4\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"4\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-records-notice-sorn\",\"attributes\":{\"title\":\"System of Records Notice (SORN)\",\"hierarchy\":[\"4\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Resources\",\"hierarchy\":[\"4\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/privacy\",\"attributes\":{\"title\":\"Privacy at CMS\",\"hierarchy\":[\"4\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-breach-response-handbook\",\"attributes\":{\"title\":\"CMS Breach Response Handbook\",\"hierarchy\":[\"4\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/health-insurance-portability-and-accountability-act-1996-hipaa\",\"attributes\":{\"title\":\"Health Insurance Portability and Accessibility Act (HIPAA)\",\"hierarchy\":[\"4\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-privacy-impact-assessment-pia-handbook\",\"attributes\":{\"title\":\"CMS Privacy Impact Assessment (PIA) Handbook\",\"hierarchy\":[\"4\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tools \u0026 Services\",\"hierarchy\":[\"5\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Reporting \u0026 Compliance\",\"hierarchy\":[\"5\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"5\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-fisma-continuous-tracking-system-cfacts\",\"attributes\":{\"title\":\"CFACTS\",\"hierarchy\":[\"5\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports and Dashboards\",\"hierarchy\":[\"5\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"5\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"5\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"5\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"5\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"5\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-security-data-lake-sdl\",\"attributes\":{\"title\":\"CMS Security Data Lake (SDL)\",\"hierarchy\":[\"5\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tests \u0026 Assessments\",\"hierarchy\":[\"5\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"5\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"5\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"5\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}}],\"size\":87,\"tree\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Roles\",\"hierarchy\":[\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/information-system-security-officer-isso\",\"attributes\":{\"title\":\"Information System Security Officer (ISSO)\",\"hierarchy\":[\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook\",\"attributes\":{\"title\":\"ISSO Handbook\",\"hierarchy\":[\"0\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#getting-started-for-new-issos\",\"attributes\":{\"title\":\"Getting started (for new ISSOs)\",\"hierarchy\":[\"0\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-mentorship-program\",\"attributes\":{\"title\":\"ISSO Mentorship Program\",\"hierarchy\":[\"0\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#training\",\"attributes\":{\"title\":\"ISSO Training\",\"hierarchy\":[\"0\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/data-guardian\",\"attributes\":{\"title\":\"Data Guardian\",\"hierarchy\":[\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/data-guardian-handbook\",\"attributes\":{\"title\":\"Data Guardian Handbook\",\"hierarchy\":[\"0\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cyber-risk-advisor-cra\",\"attributes\":{\"title\":\"Cyber Risk Advisor (CRA)\",\"hierarchy\":[\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"0\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\",\"attributes\":{\"title\":\"Risk Management Handbook (RMH)\",\"hierarchy\":[\"0\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/business-system-owner\",\"attributes\":{\"title\":\"Business / System Owner (BO/SO)\",\"hierarchy\":[\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity and Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"0\",\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"0\",\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"0\",\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"0\",\"3\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Compliance \u0026 Authorization\",\"hierarchy\":[\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"Authorization to Operate (ATO)\",\"hierarchy\":[\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"About ATO at CMS\",\"hierarchy\":[\"1\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#types-of-authorizations\",\"attributes\":{\"title\":\"Types of authorizations\",\"hierarchy\":[\"1\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#ato-stakeholders\",\"attributes\":{\"title\":\"ATO stakeholders\",\"hierarchy\":[\"1\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#related-documents-and-resources\",\"attributes\":{\"title\":\"ATO tools and resources\",\"hierarchy\":[\"1\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-technical-reference-architecture-tra\",\"attributes\":{\"title\":\"CMS Technical Reference Architecture (TRA)\",\"hierarchy\":[\"1\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"Ongoing Authorization (OA)\",\"hierarchy\":[\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"About OA at CMS\",\"hierarchy\":[\"1\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa#is-my-system-eligible-for-oa\",\"attributes\":{\"title\":\"OA eligibility requirements\",\"hierarchy\":[\"1\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"1\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Assessments \u0026 Audits\",\"hierarchy\":[\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"1\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"1\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"1\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/security-impact-analysis-sia\",\"attributes\":{\"title\":\"Security Impact Analysis (SIA)\",\"hierarchy\":[\"1\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-audits\",\"attributes\":{\"title\":\"System Audits\",\"hierarchy\":[\"1\",\"2\",\"4\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Policy \u0026 Guidance\",\"hierarchy\":[\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cms-policies-and-guidance\",\"attributes\":{\"title\":\"CMS Policies and Guidance\",\"hierarchy\":[\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-acceptable-risk-safeguards-ars\",\"attributes\":{\"title\":\"CMS Acceptable Risk Safeguards (ARS)\",\"hierarchy\":[\"2\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\",\"attributes\":{\"title\":\"CMS Information Security and Privacy Policy (IS2P2)\",\"hierarchy\":[\"2\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"2\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-risk-management-framework-rmf\",\"attributes\":{\"title\":\"CMS Risk Management Framework (RMF)\",\"hierarchy\":[\"2\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/email-encryption-requirements-cms\",\"attributes\":{\"title\":\"CMS Email Encryption\",\"hierarchy\":[\"2\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/federal-policies-and-guidance\",\"attributes\":{\"title\":\"Federal Policies and Guidance\",\"hierarchy\":[\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/national-institute-standards-and-technology-nist\",\"attributes\":{\"title\":\"National Institute of Standards and Technology (NIST)\",\"hierarchy\":[\"2\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/federal-information-security-modernization-act-fisma\",\"attributes\":{\"title\":\"Federal Information Security Modernization Act (FISMA)\",\"hierarchy\":[\"2\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/fedramp\",\"attributes\":{\"title\":\"Federal Risk and Authorization Management Program (FedRAMP)\",\"hierarchy\":[\"2\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"2\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/application-security\",\"attributes\":{\"title\":\"Application Security\",\"hierarchy\":[\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"3\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"3\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"3\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/software-bill-materials-sbom\",\"attributes\":{\"title\":\"Software Bill of Materials (SBOM)\",\"hierarchy\":[\"3\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/security-operations\",\"attributes\":{\"title\":\"Security Operations\",\"hierarchy\":[\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\",\"attributes\":{\"title\":\"Incident Response\",\"hierarchy\":[\"3\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"3\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"3\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/risk-management-and-reporting\",\"attributes\":{\"title\":\"Risk Management and Reporting\",\"hierarchy\":[\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"3\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports\",\"hierarchy\":[\"3\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/plan-action-and-milestones-poam\",\"attributes\":{\"title\":\"Plan of Action and Milestones (POA\u0026M)\",\"hierarchy\":[\"3\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy\",\"hierarchy\":[\"4\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Agreements\",\"hierarchy\":[\"4\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"4\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"4\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Activities\",\"hierarchy\":[\"4\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/breach-response\",\"attributes\":{\"title\":\"Breach Response\",\"hierarchy\":[\"4\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"4\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-records-notice-sorn\",\"attributes\":{\"title\":\"System of Records Notice (SORN)\",\"hierarchy\":[\"4\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Resources\",\"hierarchy\":[\"4\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/privacy\",\"attributes\":{\"title\":\"Privacy at CMS\",\"hierarchy\":[\"4\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-breach-response-handbook\",\"attributes\":{\"title\":\"CMS Breach Response Handbook\",\"hierarchy\":[\"4\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/health-insurance-portability-and-accountability-act-1996-hipaa\",\"attributes\":{\"title\":\"Health Insurance Portability and Accessibility Act (HIPAA)\",\"hierarchy\":[\"4\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-privacy-impact-assessment-pia-handbook\",\"attributes\":{\"title\":\"CMS Privacy Impact Assessment (PIA) Handbook\",\"hierarchy\":[\"4\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tools \u0026 Services\",\"hierarchy\":[\"5\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Reporting \u0026 Compliance\",\"hierarchy\":[\"5\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"5\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-fisma-continuous-tracking-system-cfacts\",\"attributes\":{\"title\":\"CFACTS\",\"hierarchy\":[\"5\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports and Dashboards\",\"hierarchy\":[\"5\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"5\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"5\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"5\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"5\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"5\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-security-data-lake-sdl\",\"attributes\":{\"title\":\"CMS Security Data Lake (SDL)\",\"hierarchy\":[\"5\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tests \u0026 Assessments\",\"hierarchy\":[\"5\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"5\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"5\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"5\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]}]}"])</script><script>self.__next_f.push([1,"9:[\"$\",\"html\",null,{\"lang\":\"en\",\"children\":[[\"$\",\"head\",null,{\"children\":[\"$\",\"$Ld\",null,{\"src\":\"/assets/javascript/uswds-init.min.js\",\"strategy\":\"beforeInteractive\"}]}],[\"$\",\"body\",null,{\"children\":[[[\"$\",\"a\",null,{\"className\":\"usa-skipnav\",\"href\":\"#main\",\"children\":\"Skip to main content\"}],[\"$\",\"section\",null,{\"className\":\"usa-banner\",\"aria-label\":\"Official website of the United States government\",\"children\":[\"$\",\"div\",null,{\"className\":\"usa-accordion\",\"children\":[[\"$\",\"header\",null,{\"className\":\"usa-banner__header\",\"children\":[\"$\",\"div\",null,{\"className\":\"usa-banner__inner\",\"children\":[[\"$\",\"div\",null,{\"className\":\"grid-col-auto\",\"children\":[\"$\",\"$Le\",null,{\"aria-hidden\":\"true\",\"className\":\"usa-banner__header-flag\",\"src\":\"/assets/img/us_flag_small.png\",\"alt\":\"\",\"width\":\"16\",\"height\":\"11\"}]}],[\"$\",\"div\",null,{\"className\":\"grid-col-fill tablet:grid-col-auto\",\"aria-hidden\":\"true\",\"children\":[[\"$\",\"p\",null,{\"className\":\"usa-banner__header-text\",\"children\":\"An official website of the United States government\"}],[\"$\",\"p\",null,{\"className\":\"usa-banner__header-action\",\"children\":\"Here's how you know\"}]]}],[\"$\",\"button\",null,{\"type\":\"button\",\"className\":\"usa-accordion__button usa-banner__button\",\"aria-expanded\":\"false\",\"aria-controls\":\"gov-banner-default-default\",\"children\":[\"$\",\"span\",null,{\"className\":\"usa-banner__button-text\",\"children\":\"Here's how you know\"}]}]]}]}],[\"$\",\"div\",null,{\"className\":\"usa-banner__content usa-accordion__content\",\"id\":\"gov-banner-default-default\",\"hidden\":true,\"children\":[\"$\",\"div\",null,{\"className\":\"grid-row grid-gap-lg\",\"children\":[[\"$\",\"div\",null,{\"className\":\"usa-banner__guidance tablet:grid-col-6\",\"children\":[[\"$\",\"$Le\",null,{\"className\":\"usa-banner__icon usa-media-block__img\",\"src\":{\"src\":\"/_next/static/media/icon-dot-gov.3e9cb1b5.svg\",\"height\":64,\"width\":64,\"blurWidth\":0,\"blurHeight\":0},\"role\":\"img\",\"alt\":\"\",\"aria-hidden\":\"true\",\"width\":\"40\",\"height\":\"40\"}],[\"$\",\"div\",null,{\"className\":\"usa-media-block__body\",\"children\":[\"$\",\"p\",null,{\"children\":[[\"$\",\"strong\",null,{\"children\":\"Official websites use .gov\"}],[\"$\",\"br\",null,{}],\"A \",[\"$\",\"strong\",null,{\"children\":\".gov\"}],\" website belongs to an official government organization in the United States.\"]}]}]]}],[\"$\",\"div\",null,{\"className\":\"usa-banner__guidance tablet:grid-col-6\",\"children\":[[\"$\",\"$Le\",null,{\"className\":\"usa-banner__icon usa-media-block__img\",\"src\":{\"src\":\"/_next/static/media/icon-https.e7f1a222.svg\",\"height\":64,\"width\":64,\"blurWidth\":0,\"blurHeight\":0},\"role\":\"img\",\"alt\":\"\",\"aria-hidden\":\"true\",\"width\":\"40\",\"height\":\"40\"}],[\"$\",\"div\",null,{\"className\":\"usa-media-block__body\",\"children\":[\"$\",\"p\",null,{\"children\":[[\"$\",\"strong\",null,{\"children\":\"Secure .gov websites use HTTPS\"}],[\"$\",\"br\",null,{}],\"A \",[\"$\",\"strong\",null,{\"children\":\"lock\"}],\" (\",[\"$\",\"span\",null,{\"className\":\"icon-lock\",\"children\":[\"$\",\"svg\",null,{\"xmlns\":\"http://www.w3.org/2000/svg\",\"width\":\"52\",\"height\":\"64\",\"viewBox\":\"0 0 52 64\",\"className\":\"usa-banner__lock-image\",\"role\":\"img\",\"aria-labelledby\":\"banner-lock-description-default\",\"focusable\":\"false\",\"children\":[[\"$\",\"title\",null,{\"id\":\"banner-lock-title-default\",\"children\":\"Lock\"}],[\"$\",\"desc\",null,{\"id\":\"banner-lock-description-default\",\"children\":\"Locked padlock icon\"}],[\"$\",\"path\",null,{\"fill\":\"#000000\",\"fillRule\":\"evenodd\",\"d\":\"M26 0c10.493 0 19 8.507 19 19v9h3a4 4 0 0 1 4 4v28a4 4 0 0 1-4 4H4a4 4 0 0 1-4-4V32a4 4 0 0 1 4-4h3v-9C7 8.507 15.507 0 26 0zm0 8c-5.979 0-10.843 4.77-10.996 10.712L15 19v9h22v-9c0-6.075-4.925-11-11-11z\"}]]}]}],\") or \",[\"$\",\"strong\",null,{\"children\":\"https://\"}],\" means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.\"]}]}]]}]]}]}]]}]}]],[\"$\",\"$Lf\",null,{\"value\":\"$10\",\"children\":[[\"$\",\"div\",null,{\"className\":\"usa-overlay\"}],[\"$\",\"header\",null,{\"className\":\"usa-header usa-header--extended\",\"children\":[[\"$\",\"div\",null,{\"className\":\"bg-primary-dark\",\"children\":[\"$\",\"div\",null,{\"className\":\"usa-navbar\",\"children\":[[\"$\",\"div\",null,{\"className\":\"usa-logo padding-y-4 padding-right-3\",\"id\":\"CyberGeek-logo\",\"children\":[\"$\",\"$L11\",null,{\"href\":\"/\",\"title\":\"CMS CyberGeek Home\",\"children\":[\"$\",\"$Le\",null,{\"src\":{\"src\":\"/_next/static/media/CyberGeek-logo.8e9bbd2b.svg\",\"height\":50,\"width\":425,\"blurWidth\":0,\"blurHeight\":0},\"alt\":\"CyberGeek logo\",\"width\":\"298\",\"height\":\"35\",\"priority\":true}]}]}],[\"$\",\"button\",null,{\"aria-label\":\"Open menu\",\"type\":\"button\",\"className\":\"usa-menu-btn\",\"data-cy\":\"menu-button\",\"children\":\"Menu\"}]]}]}],[\"$\",\"$L12\",null,{}]]}]]}],[\"$\",\"main\",null,{\"id\":\"main\",\"children\":[\"$\",\"$L6\",null,{\"parallelRouterKey\":\"children\",\"segmentPath\":[\"children\"],\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L13\",null,{\"children\":[\"$\",\"$L8\",null,{}]}],\"templateStyles\":[],\"templateScripts\":[],\"notFound\":[\"$\",\"section\",null,{\"className\":\"hero hero--theme-content-not-found undefined\",\"children\":[[\"$\",\"$Le\",null,{\"alt\":\"404 page not found\",\"className\":\"hero__graphic\",\"priority\":true,\"src\":{\"src\":\"/_next/static/media/content-not-found-graphic.8f104f47.svg\",\"height\":551,\"width\":948,\"blurWidth\":0,\"blurHeight\":0}}],[\"$\",\"div\",null,{\"className\":\"maxw-widescreen margin-x-auto padding-x-2 desktop:padding-x-0 padding-top-4 padding-bottom-6 desktop:padding-y-7\",\"children\":[\"$\",\"div\",null,{\"className\":\"tablet:grid-container position-relative \",\"children\":[\"$\",\"div\",null,{\"className\":\"hero__row grid-row grid-gap\",\"children\":[[\"$\",\"div\",null,{\"className\":\"tablet:grid-col-5 widescreen:position-relative\",\"children\":[false,false]}],[\"$\",\"div\",null,{\"className\":\"hero__column tablet:grid-col-7 flow padding-bottom-2\",\"children\":[\"$undefined\",\"$undefined\",false,[\"$\",\"h1\",null,{\"className\":\"hero__heading margin-0 line-height-sans-3 desktop:line-height-sans-2\",\"children\":\"We can't find that page.\"}],\"$undefined\",\"$undefined\",false,[\"$\",\"div\",null,{\"children\":[[\"$\",\"div\",null,{\"className\":\"hero__description\",\"children\":[[\"The page you're looking for may have been moved or retired. You can\",\" \",[\"$\",\"$L11\",null,{\"href\":\"/\",\"children\":\"visit our home page\"}],\" or use the search box to find helpful resources.\"]]}],[\"$\",\"div\",null,{\"className\":\"margin-top-6 search-container\",\"children\":[\"$\",\"$L14\",null,{\"theme\":\"content-not-found\"}]}]]}],false]}],false,false]}]}]}]]}],\"notFoundStyles\":[]}]}],[\"$\",\"$L15\",null,{}],[\"$\",\"$L16\",null,{}],[\"$\",\"$Ld\",null,{\"src\":\"/assets/javascript/uswds.min.js\",\"strategy\":\"beforeInteractive\"}]]}]]}]\n"])</script><script>self.__next_f.push([1,"17:I[9461,[\"866\",\"static/chunks/e37a0b60-b74be3d42787b18d.js\",\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"904\",\"static/chunks/904-dbddf7494c3e6975.js\",\"972\",\"static/chunks/972-6e520d137ef194fb.js\",\"549\",\"static/chunks/549-c87c1c3bbacc319f.js\",\"192\",\"static/chunks/app/learn/%5Bslug%5D/page-5b91cdc45a95ebbe.js\"],\"default\"]\n18:Tced,"])</script><script>self.__next_f.push([1,"\u003ch2\u003eWhat are the CMS Security and Privacy Handbooks?\u003c/h2\u003e\u003cp\u003eThe CMS Security and Privacy Handbooks help CMS staff and contractors to follow federal policies and standards that keep CMS information and systems safe. They provide practical guidance for implementing the requirements of the \u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS Information Systems Security and Privacy Policy (IS2P2)\u003c/a\u003e and the \u003ca href=\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eAcceptable Risk Safeguards (ARS)\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003ch3\u003eWhat authority do the Handbooks have?\u003c/h3\u003e\u003cp\u003eCMS has several levels of policy and guidance for the information security and privacy program:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePolicies and standards\u003c/strong\u003e, which are enterprise-level directives and the details for how they must be implemented. Our policies and standards are the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS Information System Security and Privacy Policy (IS2P2)\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS Acceptable Risk Safeguards (ARS)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProgram plans\u003c/strong\u003e, which explain how the high-level security and privacy programs at CMS uphold the policies and standards, laying out a roadmap for all ISPG activities. Our program plans include the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-program-plan\"\u003ePrivacy Program Plan\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-cyber-risk-management-plan-crmp\"\u003eCMS Cyber Risk Management Plan (CRMP)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProcedural handbooks\u003c/strong\u003e, which give practical guidance about how to implement the requirements found within the policies, standards, and program plans. Our procedural handbooks are the \u003ca href=\"https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks\"\u003eCMS Security and Privacy Handbooks\u003c/a\u003e – a go-to resource for anyone who is involved with the work of keeping CMS systems and data safe.\u003c/p\u003e\u003cp\u003eThe Handbooks are provided as \u003cstrong\u003ereliable guidance\u003c/strong\u003e approved by the CMS Chief Information Security Officer (CISO), who is responsible for implementing the agency-wide information security program. The Handbooks support the policies and standards that CMS uses to meet requirements from higher-level authorities such as the Department of\u0026nbsp; Health and Human Services (HHS).\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe Handbooks also provide \u003cstrong\u003estep-by-step instructions\u003c/strong\u003e for CMS security and privacy activities such as \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-impact-assessment-pia-handbook\"\u003ePrivacy Impact Assessment\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/policy-guidance/threat-modeling-handbook\"\u003eThreat Modeling\u003c/a\u003e, and more.\u003c/p\u003e\u003cp\u003eThese Handbooks do not supersede any applicable laws, existing labor management agreements, or higher-level agency directives or other governance documents. To learn more about the authorities, directives and laws that govern the CMS security and privacy program, see the CMS Information Security and Privacy Policy (IS2P2).\u003c/p\u003e"])</script><script>self.__next_f.push([1,"19:Tced,"])</script><script>self.__next_f.push([1,"\u003ch2\u003eWhat are the CMS Security and Privacy Handbooks?\u003c/h2\u003e\u003cp\u003eThe CMS Security and Privacy Handbooks help CMS staff and contractors to follow federal policies and standards that keep CMS information and systems safe. They provide practical guidance for implementing the requirements of the \u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS Information Systems Security and Privacy Policy (IS2P2)\u003c/a\u003e and the \u003ca href=\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eAcceptable Risk Safeguards (ARS)\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003ch3\u003eWhat authority do the Handbooks have?\u003c/h3\u003e\u003cp\u003eCMS has several levels of policy and guidance for the information security and privacy program:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePolicies and standards\u003c/strong\u003e, which are enterprise-level directives and the details for how they must be implemented. Our policies and standards are the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS Information System Security and Privacy Policy (IS2P2)\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS Acceptable Risk Safeguards (ARS)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProgram plans\u003c/strong\u003e, which explain how the high-level security and privacy programs at CMS uphold the policies and standards, laying out a roadmap for all ISPG activities. Our program plans include the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-program-plan\"\u003ePrivacy Program Plan\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-cyber-risk-management-plan-crmp\"\u003eCMS Cyber Risk Management Plan (CRMP)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProcedural handbooks\u003c/strong\u003e, which give practical guidance about how to implement the requirements found within the policies, standards, and program plans. Our procedural handbooks are the \u003ca href=\"https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks\"\u003eCMS Security and Privacy Handbooks\u003c/a\u003e – a go-to resource for anyone who is involved with the work of keeping CMS systems and data safe.\u003c/p\u003e\u003cp\u003eThe Handbooks are provided as \u003cstrong\u003ereliable guidance\u003c/strong\u003e approved by the CMS Chief Information Security Officer (CISO), who is responsible for implementing the agency-wide information security program. The Handbooks support the policies and standards that CMS uses to meet requirements from higher-level authorities such as the Department of\u0026nbsp; Health and Human Services (HHS).\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe Handbooks also provide \u003cstrong\u003estep-by-step instructions\u003c/strong\u003e for CMS security and privacy activities such as \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-impact-assessment-pia-handbook\"\u003ePrivacy Impact Assessment\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/policy-guidance/threat-modeling-handbook\"\u003eThreat Modeling\u003c/a\u003e, and more.\u003c/p\u003e\u003cp\u003eThese Handbooks do not supersede any applicable laws, existing labor management agreements, or higher-level agency directives or other governance documents. To learn more about the authorities, directives and laws that govern the CMS security and privacy program, see the CMS Information Security and Privacy Policy (IS2P2).\u003c/p\u003e"])</script><script>self.__next_f.push([1,"1a:Td96,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eRisk Management Handbook (RMH) chapters\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe CMS Risk Management Handbook (RMH) chapters are a series of procedures that support CMS policies and standards, mapped to specific control families in the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-risk-management-framework-rmf\"\u003eNIST Risk Management Framework\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003eOver time, \u003cstrong\u003ethe RMH chapters will be modified and absorbed into the broader CMS Security and Privacy Handbooks\u003c/strong\u003e for a more flexible approach to procedural guidance – not dependent on specific security controls, but still covering all the topics needed to help CMS staff and contractors follow policies, standards, and best practices.\u003c/p\u003e\u003cp\u003eUse the links below to access the chapters of the Risk Management Handbook. Note that some chapters may not be listed here, as the RMH is evolving.\u003c/p\u003e\u003cul\u003e\u003cli\u003eAre you looking for\u0026nbsp;\u003cem\u003eRMH Chapter 1: Access Control\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-access-control-handbook\"\u003eCMS Access Control Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-2-awareness-and-training\"\u003eRMH Chapter 2: Awareness and Training\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eRMH Chapter 4: Assessment and Authorization\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\"\u003eRMH Chapter 5: Configuration Management\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 6: Contingency Planning\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-system-contingency-plan-iscp-handbook\"\u003eCMS Information System Contingency Plan (ISCP) Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\"\u003eRMH Chapter 8: Incident Response\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-9-maintenance-ma\"\u003eRMH Chapter 9: Maintenance\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 10: Media Protection\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-media-protection-mp-handbook\"\u003eCMS Media Protection Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-11-physical-environmental-protection\"\u003eRMH Chapter 11: Physical and Environmental Protection\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-12-security-privacy-planning-pl\"\u003eRMH Chapter 12: Security and Privacy Planning\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-13-personnel-security-ps\"\u003eRMH Chapter 13: Personnel Security\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-14-risk-assessment-ra\"\u003eRMH Chapter 14: Risk Assessment\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-15-system-services-acquisition\"\u003eRMH Chapter 15: System and Services Acquisition\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-16-system-communications-protection\"\u003eRMH Chapter 16: System and Communications Protection\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 19: Privacy Procedures\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-program-plan\"\u003ePrivacy Program Plan\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/ispg/privacy\"\u003ewhole collection of Privacy resources\u003c/a\u003e\u0026nbsp;here on the ISPG website.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"1b:Td96,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eRisk Management Handbook (RMH) chapters\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe CMS Risk Management Handbook (RMH) chapters are a series of procedures that support CMS policies and standards, mapped to specific control families in the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-risk-management-framework-rmf\"\u003eNIST Risk Management Framework\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003eOver time, \u003cstrong\u003ethe RMH chapters will be modified and absorbed into the broader CMS Security and Privacy Handbooks\u003c/strong\u003e for a more flexible approach to procedural guidance – not dependent on specific security controls, but still covering all the topics needed to help CMS staff and contractors follow policies, standards, and best practices.\u003c/p\u003e\u003cp\u003eUse the links below to access the chapters of the Risk Management Handbook. Note that some chapters may not be listed here, as the RMH is evolving.\u003c/p\u003e\u003cul\u003e\u003cli\u003eAre you looking for\u0026nbsp;\u003cem\u003eRMH Chapter 1: Access Control\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-access-control-handbook\"\u003eCMS Access Control Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-2-awareness-and-training\"\u003eRMH Chapter 2: Awareness and Training\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eRMH Chapter 4: Assessment and Authorization\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\"\u003eRMH Chapter 5: Configuration Management\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 6: Contingency Planning\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-system-contingency-plan-iscp-handbook\"\u003eCMS Information System Contingency Plan (ISCP) Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\"\u003eRMH Chapter 8: Incident Response\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-9-maintenance-ma\"\u003eRMH Chapter 9: Maintenance\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 10: Media Protection\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-media-protection-mp-handbook\"\u003eCMS Media Protection Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-11-physical-environmental-protection\"\u003eRMH Chapter 11: Physical and Environmental Protection\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-12-security-privacy-planning-pl\"\u003eRMH Chapter 12: Security and Privacy Planning\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-13-personnel-security-ps\"\u003eRMH Chapter 13: Personnel Security\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-14-risk-assessment-ra\"\u003eRMH Chapter 14: Risk Assessment\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-15-system-services-acquisition\"\u003eRMH Chapter 15: System and Services Acquisition\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-16-system-communications-protection\"\u003eRMH Chapter 16: System and Communications Protection\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 19: Privacy Procedures\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-program-plan\"\u003ePrivacy Program Plan\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/ispg/privacy\"\u003ewhole collection of Privacy resources\u003c/a\u003e\u0026nbsp;here on the ISPG website.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"1c:T12d87,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccess is the ability to make use of any system resource. \u003ca href=\"https://csrc.nist.gov/glossary/term/access_control\"\u003eAccess Control (AC)\u003c/a\u003e is the process of granting or denying specific requests to:\u003c/p\u003e\u003col\u003e\u003cli\u003eObtain and use the information and related information processing services\u003c/li\u003e\u003cli\u003eEnter specific physical facilities (e.g., federal buildings, military establishments, border crossing entrances)\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAccess Control entails the regulation of who or what is allowed to access resources in an information system or network. As an important aspect of information security, access control helps to prevent unauthorized access to systems, services, and data.\u003c/p\u003e\u003cp\u003eAccess Control focuses on how the organization must limit system access to authorized users, to processes acting on behalf of authorized users, or to devices (including other systems), and how the organization must limit the types of transactions and functions that authorized users are permitted to conduct. Access Control can be implemented in various ways, including but not limited to the use of passwords, biometric authentication, and permissions assigned to specific users or groups. The level of access granted to an individual or a system may vary depending on their roles or responsibilities within an organization.\u003c/p\u003e\u003cp\u003eAccess control, a selective restriction of access to systems or data, consists of two main components: authentication and authorization. Authentication is the verification of the identity of a user, process, or device, and it is often the prerequisite to allowing access to resources in a system. Authorization, on the other hand, is the process of granting or denying specific requests:\u003c/p\u003e\u003col\u003e\u003cli\u003eFor obtaining and using information and related information processing services\u003c/li\u003e\u003cli\u003eTo enter specific physical facilities (e.g., Federal buildings, military establishments, and border crossing entrances)\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAuthentication and authorization are concerned with determining the allowed activities of legitimate users and mediating every attempt to access the resources in the system or an authorized entrance into a federal facility. The access must be based on the principle of \u003ca href=\"https://csrc.nist.gov/glossary/term/least_privilege\"\u003eleast privilege\u003c/a\u003e. In some systems, complete access is granted after successful authentication of the user, but most systems require more sophisticated and complex controls. In addition to the authentication mechanism (such as a password or token), access control is concerned with how authorizations are structured. In some cases, authorization may mirror the structure of the organization, while in others it may be based on the sensitivity level of various information resources with the roles and responsibilities of the user accessing those resources.\u003c/p\u003e\u003cp\u003eThe requirements for the use or the prohibitions against the use of various system resources also vary from one system to another. For example, some information may be available to all users, some may be available to specific groups or divisions, and some may be accessible to only a few individuals or groups across the agency. While users must have access to the specific information needed to perform their jobs, denial of access to non-job-related information may be enforced. It may also be important to control the type of access that is permitted (e.g., the ability for an average user to execute, but not change, system programs). These various types of access restrictions enforce policy, and ensure that unauthorized actions are not permitted.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePurpose\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe purpose of this document is to serve as a guide for managing access by providing background information and an overview of access control policies, procedures, and processes for restricted resources and data across the Centers for Medicare \u0026amp; Medicaid (CMS).\u003c/p\u003e\u003cp\u003eTo implement the security requirements for the Access Control (AC) family, as identified in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST Special Publication (SP) 800-53 Revision 5 \u003cem\u003eSecurity and Privacy Controls for Information Systems and Organizations\u003c/em\u003e\u003c/a\u003e, \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p\"\u003eHHS \u003cem\u003ePolicy for Information Security and Privacy Protection (IS2P)\u003c/em\u003e\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS\u003cem\u003e Information Systems Security and Privacy Policy (IS2P2)\u003c/em\u003e\u003c/a\u003e\u003cem\u003e, \u003c/em\u003eand the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS\u003cem\u003e Acceptable Risk Safeguards (ARS)\u003c/em\u003e\u003c/a\u003e\u003cem\u003e, \u003c/em\u003ethis manual also defines the rules around access to resources, and how access is allowed or denied by ensuring that only authorized personnel are granted access to critical information and resources while maintaining the security and confidentiality of sensitive information and Controlled Unclassified Information (CUI).\u003c/p\u003e\u003cp\u003eThis document is also intended to provide a consistent and secure approach to managing access to information and systems by serving as a reference for all CMS federal employees, contractors, and other authorized personnel. By following the processes outlined in this manual, CMS can minimize the risk of security breaches, data theft, and unauthorized access, thereby safeguarding the confidentiality, integrity, and availability of its systems and protecting the stakeholders.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eApplicability and scope\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eFederal information systems are required to incorporate information security controls to protect the systems supporting their operations and missions. CMS is required to ensure the adequate protection of its information systems and must meet a minimum level of information security.\u003c/p\u003e\u003cp\u003eFurther, the use of controls is mandatory for federal information systems in accordance with \u003ca href=\"http://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf\"\u003eOffice of Management and Budget (OMB) Circular A-130\u003c/a\u003e, and the provisions of the Federal Information Security Modernization Act \u003ca href=\"https://www.congress.gov/bill/113th-congress/senate-bill/2521\"\u003e[FISMA]\u003c/a\u003e of 2014, which requires the implementation of minimum controls to protect federal information and information systems. This program manual, along with the CMS \u003cem\u003eARS\u003c/em\u003e, satisfies the requirements of FISMA, and OMB Policies, among other laws, regulations, and policies, and will improve communication among stakeholders on how access to information systems or networks within the agency is managed.\u003c/p\u003e\u003cp\u003eTo this, the program manual applies to all CMS personnel or entities:\u003c/p\u003e\u003cul\u003e\u003cli\u003eConducting business for CMS\u003c/li\u003e\u003cli\u003eCollecting or maintaining information for CMS\u003c/li\u003e\u003cli\u003eUsing or operating information systems on behalf of CMS, whether directly or through contractual relationships.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe lists of CMS personnel or entities include, but are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eOrganizational components, centers, or offices\u003c/li\u003e\u003cli\u003eFederal employees, contractor personnel, interns, or other non-government employees operating on behalf of CMS.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis document is also applicable to all Information Technology (IT) resources, including network and computer hardware, software and applications, mobile devices, and telecommunication systems owned or operated by (or on behalf of) CMS.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRoles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePlease refer to the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2#roles-and-responsibilities\"\u003e\u003cem\u003eCMS IS2P2\u003c/em\u003e: Roles and Responsibilities\u003c/a\u003e and \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p#7.33\"\u003e\u003cem\u003eHHS Policy for Information Security and Privacy Protection (IS2P)\u003c/em\u003e Section 7 Roles and Responsibilities\u003c/a\u003e for the specific roles of CMS staff positions, contractors, or any entity operating on behalf of CMS. Further, the responsibilities related to the specific role(s) in the \u003cem\u003eCMS IS2P2:\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eSupervisors\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cem\u003eSystem/Network Administrators\u003c/em\u003e\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eor \u003cem\u003eHHS IS2P:\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eSection 7.33 (System Administrator)\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cem\u003eSection 7.37 (Supervisor)\u003c/em\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003efor roles supporting the AC control family are as follows:\u003c/p\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eSupervisors\u0026nbsp;\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eAuthorize and (or) approve the creation of new user accounts.\u003c/li\u003e\u003cli\u003eEnsure the access role is based on the principle of least privilege to ensure the user only has the authorized access rights to systems and information that is only enough to perform the duties described within their job description.\u003c/li\u003e\u003cli\u003eEnsure the user account is disabled and (or) removed when the employee separates from the position and no longer requires access. \u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eSystem Administrators [ADMIN]\u003c/strong\u003e\u003c/em\u003e\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e\u0026nbsp;\u003cbr\u003e(e.g., database administrators, network administrators, web administrators, and application administrators)\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsure that when performing administrator-type functions (e.g., as a privileged user), the ADMIN is logged on their privileged account only and their responsibilities are established to perform just those privileged functions with defined privileged commands and privileged processes.\u003c/li\u003e\u003cli\u003eFollow the established CMS system security protocols and processes as established in the \u003ca href=\"https://security.cms.gov/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e for onboarding new employees for new account creation, once the individual has completed all pre-required onboarding activities before account issuance (e.g., filing out required application for access forms and receiving the appropriate approvals, completing required security awareness and role-based training, completing any person proofing requirements, obtaining a required CMS-approved hard token credentials [PIV card, RSA token, etc.] for multi-factor authentication, etc.) or for any user requiring a modification to their account security credentials.\u003c/li\u003e\u003cli\u003eEnsure the account security credential(s) are issued to the appropriate authorized individual user.\u003c/li\u003e\u003cli\u003eEnsure all the security-related activities required are met to ensure the secure establishment and management of user accounts. (Refer to Account Management below).\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eCMS Access Control services and practices\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis section describes an overview of some of the CMS services and practices that assist in the discussion and the implementation of the AC family as outlined in the \u003cem\u003eCMS ARS \u003c/em\u003eand the \u003cem\u003eCMS IS2P2. \u003c/em\u003eThe information in this section provides some important considerations for implementing Access Control based on the mission and business requirements of CMS, its operational environments, and the assessments of organizational and system risks. The additional information contained in this section also explains the purpose of the control and the mechanisms to meet the control requirements.\u003c/p\u003e\u003cp\u003ePlease consult the CMS \u003cem\u003eARS \u003c/em\u003efor specific procedures.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccount management\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccount Management control is required to establish the requirements for managing CMS systems and user accounts throughout the account lifecycle. The Office of Information Technology (OIT) implements mechanisms that are responsible for all account management-related activities. These mechanisms help to ensure CMS personnel or entities have secure, authorized access to CMS business applications. The primary functions of an account management feature are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eRegistration\u003c/li\u003e\u003cli\u003eAuthentication\u003c/li\u003e\u003cli\u003eAuthorization\u003c/li\u003e\u003cli\u003eIdentity and User Account Lifecycle Management.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe account control mechanisms are also required to authorize and monitor the use of guest or anonymous accounts, and remove, disable, or otherwise secure unnecessary accounts.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for Account Management:\u003c/p\u003e\u003col\u003e\u003cli\u003eCMS information systems must have a documented Access Control procedure to document account life cycle activities. A description of all authorized system users, account access privileges, and other applicable account attributes must be documented.\u003c/li\u003e\u003cli\u003eAccount creation, changes, disabling, and retiring are requested using the channels documented in the applicable access control procedure or the system security and privacy plan.\u003c/li\u003e\u003cli\u003eThe following requirements are adhered to before creating, enabling, modifying, disabling, or removing accounts:\u003c/li\u003e\u003c/ol\u003e\u003cul\u003e\u003cli\u003eValid access authorization\u003c/li\u003e\u003cli\u003eIntended system usage\u003c/li\u003e\u003cli\u003eSatisfactory completion of mandatory training requirements (Security Awareness Training [SAT] in the Awareness and Training [AT] family of controls [and annually thereafter]; pre-access and role-based training within the prescribed timeframe), acknowledgment of \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eRules of Behavior for General Users\u003c/a\u003e, and signed request forms.\u003c/li\u003e\u003cli\u003eA valid justification must be supplied if access rights are above what is minimally necessary to perform the duties of the job.\u003c/li\u003e\u003cli\u003eList of functions required to perform job duties\u003c/li\u003e\u003cli\u003eAuthorization and approval from applicable information account managers as described in the system security and privacy plan.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp; \u0026nbsp;4. The Primary Information System Security Officer (P-ISSO) (or alternate) is tasked with:\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsuring access control policies and procedures are followed.\u003c/li\u003e\u003cli\u003eAuditing account management activities to ensure compliance.\u003c/li\u003e\u003cli\u003eReviewing access privileges to ensure all users have justifiable permissions.\u003c/li\u003e\u003cli\u003eEnforce account management lifecycle activities.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe \u003cem\u003eCMS ARS\u003c/em\u003e requires removing or disabling default user accounts, renaming active default user accounts, implementing a centralized control of user access administrator functions, regulating and defining the access provided to contractors, searchable automated account management results by \u003ca href=\"https://security.cms.gov/learn/cms-cybersecurity-integration-center-ccic\"\u003eCMS Cybersecurity Integration Center (CCIC)\u003c/a\u003e, and all raw security information/results from relevant automated tools must be available in an unaltered format to the CCIC.\u003c/p\u003e\u003cp\u003eAccount managers must be notified when a CMS system user is terminated or transferred, and the user’s associated account removed, disabled, revoked, or otherwise secured within a Mission/Business/System-defined timeframe, and not to exceed 30 days from the date of termination or transfer. Account managers must also be notified when there are changes in the user's system usage or need to know.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated system account management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAutomated System Account Management is required to manage, create, enable, modify, disable, revoked, retire, and remove CMS system account(s) when a user is terminated or transferred. CMS access control tools leverage the use of emails or text messaging to notify managers and users of account lifecycle events. These tools have automated capabilities to review user account activities and usage and report atypical behavior using email notifications.\u003c/p\u003e\u003cp\u003eCMS system administrators must be notified via automated email whenever a user account lifecycle event has occurred. Automated email mechanisms must be in place to support the management of system accounts. Additionally, users are emailed prior to password expiration and are allowed to make the necessary password changes.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated temporary and emergency account management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAutomated temporary and emergency account management is required to automatically remove or disable the access rights of temporary or emergency accounts after a predefined period after activation rather than at the convenience of the system administrator. Automatic removal or disabling of accounts provides a more consistent implementation.\u003c/p\u003e\u003cp\u003eCMS temporary and emergency accounts are managed in accordance with the system’s account management procedures or the security and privacy plan. These accounts are provisioned only when necessary and authorized, and they must be established with a fixed duration based on the need not to exceed the CMS parameter.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable accounts\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to automatically disable accounts that are expired, no longer associated with a user or individual, violate CMS policy, or have been inactive for a predefined period.\u0026nbsp;\u003c/p\u003e\u003cp\u003eFor an inactive account, a scheduled task reconciles the Last Login Date from the system database and locks the user account if the period reached its expiration date. Users who have not logged in during the inactivity period are marked as inactive and their accounts locked. The user will be notified at the next logon attempt that their account has been locked and can make use of the self-unlock feature or an IT Service Desk request for a user account reset.\u003c/p\u003e\u003cp\u003eAll these processes support the concepts of least privilege and least functionality that reduce the attack surface of systems.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated audit actions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS access control systems are required to utilize the capability to automatically produce event logs for system administrators to review for administrative actions. These may include account creation, modification, enabling, disabling, and removal actions for audit record review, analysis, and reporting. In addition to any other actions defined in the applicable system security and privacy plan.\u003c/p\u003e\u003cp\u003eCMS systems must be configured to log and audit the following account lifecycle events:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCreation\u003c/li\u003e\u003cli\u003eEnabling\u003c/li\u003e\u003cli\u003eModification\u003c/li\u003e\u003cli\u003eDisabling and;\u003c/li\u003e\u003cli\u003eRemoval (Retirement and Termination).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNotifications for these relevant and significant events are sent to the system administrators or managers as documented in the applicable security and privacy plan. Account actions in Active Directory (AD) are logged and exported to a Security Incident and Event Management (SIEM) tool where custom alerts are created, which notify appropriate individuals of these activities.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eInactivity logout\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eInactivity logout after a defined period reduces the risks of unauthorized access to CMS systems. This is accomplished by setting a lock on the system after 90 minutes of inactivity to prevent users from obtaining information from the display device while an authorized user is actively logged into the system or application. Users are also encouraged to lock their systems when leaving the vicinity and are required to log out at the end of a normal work period.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eUsage conditions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eClearly defined account usage conditions establish and describe the specific conditions or circumstances under which CMS system accounts can be used. These conditions help enforce the principle of least privilege, increase user accountability, and enable effective account monitoring. CMS defines these usage conditions for particular system accounts as necessary to provide adequate information protections and configure systems to enforce them.\u003c/p\u003e\u003cp\u003eThe following details the usage conditions that are set and must be met before access is granted to CMS systems:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS requires all users who have been provisioned a User ID to complete an initial and annual certification of access needs, as well as the security Computer Based Training (CBT) course. Access is revoked for users who have not complied with these requirements annually.\u003c/li\u003e\u003cli\u003eCMS users are required to accept the government warning displayed on the CMS warning banner before accessing CMS Government-Furnished Equipments (GFEs), CMS VPN connections, or CMS Virtual Desktop Infrastructure (VDI) using CITRIX Workspace connections. This warning banner is an acknowledgment of monitoring and usage restrictions.\u003c/li\u003e\u003cli\u003eAll users must complete all CMS system-related documentation including access request forms, \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eHHS rules of behavior\u003c/a\u003e for General Users, and any additional training required based on individuals with Significant Information Security Responsibilities (SISR), e.g., Role Based Training (RBT) for any user identified with significant information security and privacy responsibilities, as required in the applicable system security and privacy plan.\u003c/li\u003e\u003cli\u003eCMS users are prohibited from accessing systems from non-US locations during foreign travels without first obtaining official leadership approval. For more information on the approval process, review Chapter 10: Foreign Travel of the \u003cem\u003eCMS Physical Security Handbook\u003c/em\u003e.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAccount monitoring for atypical usage\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe administrative monitoring of activities associated with CMS system accounts is established to determine unusual and malicious use. CMS security teams monitor accounts for atypical usage that may include assessing systems at unusual days and times or from locations that are not consistent with the normal usage patterns of individuals, and for unusual information transfer volumes. Monitoring may also reveal rogue behavior by individuals or an attack in progress. There is coordination between CMS systems and the security teams through the CCIC to monitor system accounts and their usage and report to CMS incident response teams.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for monitoring user accounts for atypical usage.\u003c/p\u003e\u003cp\u003eCMS employs several security appliances and devices to assist with the ongoing monitoring of systems, as well as related system accounts, for atypical usage.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eFirewalls:\u003c/strong\u003e Network- and host-based firewalls are used to monitor traffic and generate daily reports covering the last 24 hours of activity.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity Information and Event Management (SIEM):\u003c/strong\u003e This solution is used to review logs generated from applications, databases, and servers for analysis by CMS security teams.\u003c/p\u003e\u003cp\u003eIn accordance with CMS information system Incident Response Plans, CMS CCIC should be notified immediately of potential security incidents upon discovery.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable accounts for high-risk individuals\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eDisabling the accounts for high-risk individuals reduces the risks posed by an insider threat that could adversely impact CMS IT assets, environment, operations, and individuals. Users who pose significant security or privacy risks include individuals for whom reliable evidence indicates either intention to use authorized access to a system to cause harm or through whom adversaries will cause harm.\u003c/p\u003e\u003cp\u003eDisabling accounts of high-risk individuals is a minimum requirement for the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior\u003c/a\u003e for Use of Information and IT Resources because of the possibility of abusing access privileges to sensitive information and CUI, including information protected under the Privacy Act.\u003c/p\u003e\u003cp\u003eAccount management activities must be expedited for the revocation of access for high-risk user accounts. Notification is sent to the appropriate security personnel as documented in the system security and privacy plan using the appropriate channels (email or phone). After being notified, the account must be disabled within a reasonable time frame not to exceed the CMS-established parameter from the time the high-risk account is identified.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccess enforcement\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccess control policies and the associated access enforcement mechanisms are employed to automatically control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the systems. These access control mechanisms must restrict access to any sensitive information, CUI or personally identifiable information (PII) and protected health information (PHI).\u003c/p\u003e\u003cp\u003eCMS systems are configured to enforce approved authorizations for logical access to information and system resources that support its mission and business functions, in accordance with applicable access control policies.\u003c/p\u003e\u003cp\u003eFurther, access enforcement mechanisms can be employed at the application and service level to provide increased information security and privacy. Assigned privileges and rules are used to allow logical access to systems, applications, and databases. These privileges are assigned during the account creation and modification account lifecycle.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eControlled release\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eControlled release of information ensures systems implement technical or procedural means to validate the controls implemented by any external systems before releasing information to them. All external systems or entities (i.e., departments, agencies, or commercial entities not managed by CMS) must provide controls that are commensurate with those implemented by CMS to protect the released information. The means used to determine the adequacy of the controls provided by the recipient systems may include conducting periodic assessments (inspections/tests), establishing agreements between CMS and external entities, or some other process. The adequacy of the implemented controls on those external systems ensures a consistent adjudication of the security and privacy policy that protects the information and individuals’ privacy.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eIndividual access\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS allow access to individuals that enable them to review personally identifiable information about them collected via legislative mandates and healthcare programs. Access helps individuals to develop an understanding of how their personally identifiable information is processed, handled, and disseminated to ensure their data is accurate and secure. Access mechanisms can include request forms and application interfaces. As stipulated by the Privacy Act, individual record access procedures are contained in systems of record notices (SORN) and the SORNs published on the Federal Register and CMS/HHS websites.\u003c/p\u003e\u003cp\u003eHowever, individual access to certain types of records contained in the HHS Exempt Systems of Records may be exempt, in full or in part, from certain requirements of the Privacy Act, based on rulemakings promulgated under subsection (j) or (k) of the Privacy Act (5 U.S.C. § 552a(j), (k)). Note that 5 U.S.C §. 552a(d)(5) excludes material compiled in reasonable anticipation of a civil action or proceeding from the Privacy Act's access requirement, in all systems of records, without the need for rulemaking.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eInformation flow enforcement\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eInformation flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) without regard to subsequent access to that information. Flow control restrictions may include blocking external traffic that claims to be from within CMS, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from CMS's internal web proxy server, and limiting information transfers between CMS and other external entities based on data structures and content.\u003c/p\u003e\u003cp\u003eTransferring information between CMS and other external entities may require an agreement specifying how the information flow is enforced using \u003ca href=\"https://security.cms.gov/learn/cms-interconnection-security-agreement-isa\"\u003einterconnection security agreements (ISA)\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cms-information-exchange-agreement-iea\"\u003einformation exchange security agreements\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cms-memorandum-understanding-mou\"\u003ememoranda of understanding or agreement (MOU/MOA)\u003c/a\u003e, service level agreements (SLA), or other exchange agreements (as defined in the applicable security and privacy plans).\u003c/p\u003e\u003cp\u003eInformation flow enforcement may also include prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regarding mechanisms to reassign security or privacy attributes and labels.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing information flow enforcement.\u003c/p\u003e\u003cp\u003eCMS uses a variety of methods and applications to enforce information flow with systems and between interconnected systems.\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CMS access control systems are configured to enforce approved authorizations within CMS information systems and other interconnections. For more information on interconnections and information sharing, please review AC-21 in the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e\u003cem\u003e.\u003c/em\u003e\u003c/li\u003e\u003cli\u003eVirtual Local Area Networks (VLANs) are used to provide environment and zone separation with firewall device control between each interconnected VLAN. Firewall rules are then configured to restrict information flows to only authorized users.\u003c/li\u003e\u003cli\u003eInterconnection between different server types within the CMS information system environment is controlled by network devices including firewalls. Rules are set up to allow traffic to authorized destination internet protocol (IP) addresses only.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eFlow control of encrypted information\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to prevent encrypted information from bypassing information flow control mechanisms by either blocking the flow of the encrypted information or terminating communications sessions that attempt to pass encrypted information. Flow control mechanisms may include content checking, security policy filters, and data type identifiers. The term encryption is extended to cover encoded data that are not recognized by the filtering mechanisms.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSeparation of duties\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSeparation of duties for CMS’s accounts is enforced to address the potential for abuse of authorized privileges and reduces the risk of malevolent activity without collusion. Each individual`s responsibilities and privileges within CMS`s environment are defined in a way that inhibits intentional or inadvertent unauthorized activity. Through the use of job codes, roles, and access rights, the workflows for authorization are separated in the CMS environment. A job code is a role that grants a group of users, access to defined resources. All ISSOs are required to ensure that these requirements are implemented effectively and meet the minimum control standards within the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e in their respective systems during authorization.\u003c/p\u003e\u003cp\u003eFurther, implementing separation of duties control reduces the risk of inappropriate access to CMS's sensitive information and CUI (e.g., separating employees that perform security and breach investigations from routine mission and business functions).\u003c/p\u003e\u003cp\u003eCMS Business owners control the access to their respective CMS systems. They create privileges that limit an individual's account access only to those systems for which there is a business need. Access rights are established while considering the separation of duties based on the following factors:\u003c/p\u003e\u003cul\u003e\u003cli\u003eDividing mission functions and information system support functions among different individuals and/or roles.\u003c/li\u003e\u003cli\u003eConducting information system support functions with different individuals (e.g., system management, programming, configuration management, quality assurance and testing, and network security).\u003c/li\u003e\u003cli\u003eEnsuring security personnel administering access control functions do not also administer approval or audit functions.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eLeast privilege\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS employs the principle of least privilege to ensure that its information system accounts are provisioned at privilege levels no higher than necessary to accomplish the mission/business functions. In other words, the system access privileges are only enough, i.e., at a minimum, for a user to perform their assigned duties as prescribed in their job descriptions. CMS systems are configured to prevent non-privileged accounts from having access to security or audit-related settings and controls. It is strictly prohibited to knowingly exceed authorized access according to the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eAt CMS, role-based access control is used to restrict access to system functions only to designated individuals. The restrictions must be based on the minimum necessary access required to complete specific system activities. These restrictions must be included in system-specific documentation, and are necessary to ensure that only authorized users are permitted access to files, directories, drives, workstations, servers, network shares, ports, protocols, and services that are expressly required for the performance of their job duties. Unnecessary access rights associated with services that are not required for the operation of the system should be disabled.\u003c/p\u003e\u003cp\u003eThe concept of least privilege aligns with the notion of limiting access to CMS's sensitive information and CUI to those individuals with a documented need to know in the performance of their job duties.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthorize access to security functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eSecurity functions in CMS are limited only to authorized personnel. Security functions include but are not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), configuring settings for events to be audited, and establishing intrusion detection parameters.\u003c/p\u003e\u003cp\u003eCMS personnel classified as privileged users, according to the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS \u003cem\u003eIS2P2\u003c/em\u003e\u003c/a\u003e, are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe following details the CMS-specific process for authorizing access to security functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAccess is granted based on the privileged role and approved job codes, with privileged functions restricted to individuals with administrative or security functionality requirements.\u003c/li\u003e\u003cli\u003eThe privileged account is restricted to privileged functions only and cannot be used to perform normal user (i.e., non-privileged accounts) functions concurrently.\u003c/li\u003e\u003cli\u003eApproved servers may use RBAC which is implemented using Active Directory (AD) group memberships. Non-privileged accounts have no access to servers.\u003c/li\u003e\u003cli\u003eSystem configurations and parameters are by group policy (GPO).\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eNon-privileged access for non-security functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe implementation of non-privileged access for nonsecurity functions limits security exposure or incidents that might occur when users perform operations from within privileged accounts or roles. CMS-privileged accounts or roles must be used only when necessary to perform system administration and security duties. Also, CMS systems must be configured to prevent non-privileged users from executing privileged functions.\u003c/p\u003e\u003cp\u003eCMS-privileged users with access to security functions are provisioned with and required to use their non-privileged accounts to perform duties that do not require that level of access. The separation of privileged and non-privileged accounts also prevents unintended or unauthorized loss, modification, or exposure. For example, a System Administrator (SYSADMIN) would have a separate account to perform SYSADMIN functions, and a typical USER account to perform normal user functions such as email, application access [Word Documents, Spreadsheets, Presentations, etc.], etc. The SYSADMIN cannot perform SYSADMIN functions under the typical USER account or role.\u003c/p\u003e\u003cp\u003eIn addition, the typical USER account or role cannot perform SYSADMIN-type functions such as administration/ management of the following: operating systems, network operations (telecommunications devices, firewalls, DMZ, servers, database administration, etc.), application servers, database servers, etc. In other words, any operation that would require Operating System (OS), ADMIN, or root-level access to perform ADMIN-type services or operations.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNetwork access to privileged commands\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS restricts the ability to perform privileged commands across the network connection as opposed to the local access on its systems. CMS limits network access to activities requiring elevated privileges to situations where there is a compelling operational need. For example, a compelling operational need may include routine administration (management) of remote security and infrastructure devices across a dedicated management network (see the \u003cem\u003eCMS Technical Reference Architecture [TRA]\u003c/em\u003e for additional information).\u003c/p\u003e\u003cp\u003eNetwork access to privileged commands is limited to specific roles listed as privileged users in \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p\"\u003e\u003cem\u003eCMS IS2P2\u003c/em\u003e\u003c/a\u003e. These roles are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators\u0026nbsp;\u003c/li\u003e\u003cli\u003eAdditional roles as documented in the System Security and Privacy Plan (SSPP).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS personnel are approved for such access by requesting the necessary roles or privileges. The process of requesting and approving these roles or privileges (as documented in the system security and privacy plan) acts as a control to ensure the privilege is being assigned to the right user.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrivileged accounts\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS limits who is authorized to perform administrative or security functions on its systems. These functions may include configuring access permissions, setting audit logs, and performing system management functions. This level of access needs to be limited because it further protects sensitive information and CUI from being comprised by reducing the number of individuals who possess unnecessary high privileges.\u003c/p\u003e\u003cp\u003ePrivileged accounts are limited only to specific roles that require the performance of privileged functions in the CMS environment. These roles are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators\u0026nbsp;\u003c/li\u003e\u003cli\u003eAdditional roles as documented in the SSPP.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS personnel are approved for such access through the appropriate account privileges. The process of requesting and approving these account privileges (as documented in the SSPP) acts as a control to ensure the privilege is being assigned to the right user.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eReview of user privileges\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIn CMS, certain assigned user privileges may change over time to reflect changes in the mission and business functions, environments of operation, technologies, or threats. A periodic review of all assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid. If the need cannot be revalidated, appropriate corrective actions must be taken to address it.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eLog use of privileged functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eLog the use of all privileged functions to ensure that there is accountability for all CMS system accounts with privileged functions because of the elevated permissions to access, and grant access, to sensitive information and CUI.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for logging the use of privileged functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS systems audit the use of privileged functions via logging user accounts that have the right to conduct privileged functions only on the system.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe audit logs must include a user account trail of privileged commands executed intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts.\u003c/li\u003e\u003cli\u003eThese logs are then audited and reviewed using a SIEM tool.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eProhibit non-privileged users from executing privileged functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eProhibit non-privileged users from executing privileged functions so that appropriate individuals have access to privileged functions only based on their roles and responsibilities. Non-privileged users may not have the same level of trust as privileged users. Privileged users have access beyond that of a non-privileged user, and as such, may have a greater ability to access sensitive information and CUI. Privileged accounts typically may have root-level access to the system at the operating system (OS) level and therefore “keys to the kingdom” level of access to all components or services of that system. For this reason, systems must have the ability to trace (audit) the actions of the user who initiated them and what actions were taken.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe assignment of privileged functions to user accounts should be based on the role and the level of responsibility of the user, while still accounting for the principle of least privilege. Privileged functions are assigned to a user account through approved roles or privileges and the approval process acts as a safeguard to ensure access is being provisioned to the right user, who have been appropriately authorized for the escalated privilege.\u0026nbsp;\u003c/p\u003e\u003cp\u003eUsers' accounts are set up to allow only the necessary functions authorized, thereby enforcing the principle of least privilege.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eUnsuccessful logon attempts\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded counteracts denial of service attacks and ensures that the user account is accessed only by the owner of that account. Automatic account lockouts are initiated by systems and are usually temporary and automatically released after a predetermined period as established by the CMS system administrators.\u003c/p\u003e\u003cp\u003eThe implementation standards contained in the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e are determined by the system’s risk categorization as stated below:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHigh:\u003c/strong\u003e Configure the information system to lock out the user account automatically after three (3) invalid login attempts during a 120-minute time window. Require the lockout to persist until released by an administrator.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eModerate:\u003c/strong\u003e Configure the information system to lock out the user account automatically after five (5) invalid login attempts during a 120-minute time window. Require the lockout to persist for a minimum of one (1) hour.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eLow:\u003c/strong\u003e Configure the information system to disable access for at least fifteen (15) minutes after five (5) invalid login attempts during a 120-minute time window.\u003c/p\u003e\u003cp\u003eCMS users will experience a lockout if they reach the maximum number of invalid login attempts. Users will be locked out indefinitely and must contact the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/Request%2520IT%2520Service.aspx\"\u003eCMS IT Service Desk\u003c/a\u003e or their system administrator to request their account to be unlocked.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSystem use notification\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS systems are configured to display an approved notification to be accepted by users before login. This notification provides appropriate security and privacy notifications as well as terms of use of the system. All CMS information systems are configured to display a system-use notification message before granting access. This is commonly referred to as a “System Warning Banner”.\u0026nbsp;\u003c/p\u003e\u003cp\u003eHHS has an established language approved for use as defined in the \u003cem\u003eCMS ARS AC-08 System Use Notification \u003c/em\u003econtrol. The system must use the HHS-approved warning banner text unless the system is collecting Federal Tax Information (FTI), then the \u003ca href=\"https://www.irs.gov/pub/irs-pdf/p1075.pdf\"\u003eIRS Publication 1075\u003c/a\u003e requires the system to use the approved text specified in Exhibit 8 Warning Banner Examples from the \u003cem\u003eIRS AC-08 System Use Notification\u003c/em\u003e control standard. The warning banner notification message must be displayed upon successful logon, obtaining an affirmation in the workflow from the user of their understanding and acceptance of the warning before gaining system access. This warning message notifies users that the CMS system is owned by the U.S. Government and describes conditions for access, acceptable use, and access limitations. The warning is presented at the secure gateway, and again at the system/device level. The approved warning/notification message should require forced user interaction and require the user to explicitly select the “I Accept” button before proceeding to log on to the system. The system should retain the notification message or banner on the screen until users take the explicit action(s) to log on to or further access the system.\u003c/p\u003e\u003cp\u003eThe warning banner language has very important legal implications for CMS and its system resources. Should content need to be added to this banner, submit the modified warning banner language to the CMS CIO for review and approval prior to implementation. If a system has character limitations related to the warning banner display, the CMS CIO can provide an abbreviated warning banner version. The \u003ca href=\"https://www.irs.gov/pub/irs-pdf/p1075.pdf\"\u003eIRS Publication 1075\u003c/a\u003e in Exhibit 8 Warning Banner Examples also has approved abbreviated warning banner versions available to use. If this banner is inconsistent with any directives, policies, regulations, or standards, notify the CMS CIO immediately.\u003c/p\u003e\u003cp\u003eAll systems and network devices under CMS control must prominently display the notice and consent banner immediately upon users’ authentication to the system, including, but not limited to, websites, web pages where substantial personal information from the public is collected, Secure File Transfer Protocol (SFTP), Secure Shell (SSH), or other services accessed.\u003c/p\u003e\u003cp\u003eThe \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003eprovides additional requirements for the content and the implementation of System Use Notifications as specified by the AC-08 System Use Notification control standard.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eConcurrent session control\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS defines and implements the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or any combination thereof. A session is defined as an encounter between an end-user interface device (e.g., computer, terminal, process) and an application, including a network logon. One user session is the time between starting the application and quitting or exiting the application. For example, if a user can use separate browsers to open concurrent sessions with the same user account and log out of any of the concurrent sessions to terminate the other sessions, safeguards must be implemented to counteract this type of action.\u003c/p\u003e\u003cp\u003eCMS limits network log-on sessions to one (1) user/network/application session at a time by implementing the appropriate configuration settings. However, if a concurrent session of more than one (1) is required for the system, it needs to be documented in the applicable SSPP and approved by the CMS Authorizing Official (AO) during the Authorized To Operate (ATO) approval process.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDevice lock\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eDevice locks are actions taken to prevent logical access to systems when a period of inactivity has been detected on a CMS user account. This control is configured to protect sensitive information and CUI from unauthorized access when CMS system users are away from their workstations for a CMS-defined period of inactivity. Identification and authentication requirements must be met for users to re-establish access to the system. Group Policy is used to configure the device lock requirements.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing device lock:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS information systems, along with GFE computers distributed to CMS Federal staff and contractors, are configured with a fifteen (15) minute device lock on the operating system. The user will be required to re-authenticate themselves to continue accessing CMS resources.\u003c/li\u003e\u003cli\u003eWindows and UNIX servers are configured to lock the application, after thirty (30) minutes of inactivity. The user will be required to re-authenticate themselves to continue accessing CMS resources.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePattern-hiding displays\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePattern-hiding displays conceal, via the device lock, information with a publicly viewable image. All CMS systems are configured to conceal information that is previously available on the display with a screen saver. Pattern-Hiding Displays mitigate against unauthorized viewing of any sensitive information and CUI, especially PII or PHI. This type of threat is commonly referred to as “shoulder surfing”.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing pattern-hiding displays:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe system conceals information previously available on the display with a screen saver built into the operating system of the GFE.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS users can make use of this display before leaving GFE computers unattended or concealing information from unauthorized personnel.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe login screen is only available by pressing CTRL-ALT-DEL.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eSession termination\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSession termination ensures that all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) continue after the session is terminated. The conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.\u003c/p\u003e\u003cp\u003eCMS systems are configured to terminate user login sessions after a certain period of inactivity. For systems-specific login sessions, the system must implement automatic session termination based on a predefined condition or trigger outlined in their respective system security and privacy plan (SSPP).\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePermitted actions without identification or authentication\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSome specific user actions are permitted on CMS systems without identification or authentication required. Systems may allow a limited number of user actions like access to CMS public websites or other publicly accessible CMS systems that do not contain any sensitive information and CUI, but only the information that is appropriate for public consumption.\u003c/p\u003e\u003cp\u003eAll CMS systems that are not intended to be utilized by the public require proper user account processes and authentication. Please refer to the \u003ca href=\"https://pages.nist.gov/800-63-4/\"\u003eNIST Special Publication (SP) 800-63\u003c/a\u003e series regarding Digital Identity Guidelines (NIST SP 800-63, SP 800-63A, SP 800-63B, SP 800-63C).\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRemote access\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eRemote access is access to CMS systems by users (or processes acting on behalf of users) that communicate through external networks (for example, the Internet or non-secure telecommunication pathways and protocols) via CMS-approved VPNs or CMS VDI via the CITRIX Workspace. The use of CMS-approved VPNs or VDI does not make the access non-remote. However, the use of VPNs or VDI, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) provides sufficient information security assurance to the organization that it can effectively treat such connections as safe internal networks. Remote access to CMS network resources is securely configured and must meet, as a minimum, the following security requirements for posture validation:\u003c/p\u003e\u003col\u003e\u003cli\u003eUp-to-date system patches\u003c/li\u003e\u003cli\u003eCurrent malware/anti-virus software with up-to-date patches\u003c/li\u003e\u003cli\u003eA host-based intrusion detection system(s)\u003c/li\u003e\u003cli\u003eDisable functionality that provides the capability for automatic execution of code and\u003c/li\u003e\u003cli\u003eEmploys CMS-required encryption which is the Federal Information Processing Standard (FIPS) 140-2 validated cryptographic module at a minimum.\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eThe following details the CMS-specific process for implementing the remote access control:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe system should utilize a CMS-approved VPN(s) or VDI to ensure the security of the sessions and the integrity of client-based applications.\u003c/li\u003e\u003cli\u003eCMS users are not allowed to access CMS systems remotely without a CMS-issued RSA hard token or \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-3.pdf\"\u003eFIPS 201\u003c/a\u003e PIV card, along with an approved EUA job code.\u003c/li\u003e\u003cli\u003eAccess to the secure CMS VPN or CMS VDI will authenticate the user account using the EUA job code.\u003c/li\u003e\u003cli\u003eThe VPN solution used by CMS also includes a Network Access Control (NAC) component that performs a security assessment and verifies the latest critical operating system patches and up-to-date malware/anti-virus signatures.\u0026nbsp;\u003c/li\u003e\u003cli\u003eIf the computer fails any one of these checks, it will be quarantined, i.e., preventing remote users from connecting to the CMS network with machines that aren't up to date with malware/anti-virus signatures or OS patch levels, and securing the computer by placing VPN login credentials into a secured area with limited or no access to the CMS network until those conditions are remediated. In the remediation process, CMS users are instructed to obtain required updates from Windows Software Update Service (WSUS) servers or other update servers.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS contractors will be notified that they will need to disconnect from the VPN and update their computers by downloading the latest Microsoft critical patches and/or antivirus signatures before access is granted.\u003c/li\u003e\u003cli\u003eRemote access for privileged functions must be permitted only for compelling operational needs, must be strictly controlled, and must be explicitly authorized, in writing, by the CMS AO, i.e., the CIO (Chief Information Officer) or his/her designated representative.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAdditional information on connecting to the CMS Network using an approved CMS VPN service can be found in the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/RemoteAccessSupport.aspx?PageView=Shared\u0026amp;InitialTabId=Ribbon.WebPartPage\u0026amp;VisibilityContext=WSSWebPartPage#Remote\"\u003eRemote Access Support\u003c/a\u003e. Additional information for CMS Federal Employees or contractors using the CMS VDI can be found at \u003ca href=\"https://vdildap.cms.gov/logon/CMS_VDI_HOW_TO_GUIDE.pdf\"\u003eCMS Employees and Contractors How-To-Guide VDI\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMonitoring and control\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to employ automated mechanisms and establish parameters that facilitate the monitoring and control of remote access. User activities are also monitored and audited to ensure compliance with CMS remote access policies, as applicable to each CMS information system. For more information on remote access, visit the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/RemoteAccessSupport.aspx?PageView=Shared\u0026amp;InitialTabId=Ribbon.WebPartPage\u0026amp;VisibilityContext=WSSWebPartPage#Remote\"\u003eCMS Remote Access Support\u003c/a\u003e website.\u003c/p\u003e\u003cp\u003eAn Intrusion Detection System (IDS) is deployed to protect and monitor the integrity of the systems. Continuous monitoring is also deployed by the CMS Information Security and Privacy Group (ISPG) to ensure compliance with CMS policies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eProtection of confidentiality and integrity using encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems shall implement cryptographic mechanisms to protect remote access sessions. All encryption solutions used throughout CMS must be \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf\"\u003eFIPS 140-3\u003c/a\u003e tested and validated. The confidentiality and integrity of remote sessions, sensitive information and CUI shall be protected with end-to-end encryption commensurate with the sensitivity level of the data.\u003c/p\u003e\u003cp\u003eSystems must utilize a CMS-approved secure VPN or VDI solution to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Every access to the CMS Secure VPN or VDI requires authentication using secure user system account credentials.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWhen applicable and available, sessions should be secured with FIPS 140-3 hardware security modules and FIPS 140-3 compliant algorithms.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManaged Access Control points\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS remote accesses must be routed through authorized and managed network access control points to protect the network connections. A Trusted Internet Connection (TIC) must be utilized for all external network connections.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing managed access control points:\u003c/p\u003e\u003cp\u003eAll systems must utilize CMS-approved secure VPN or VDI connections to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Administrative access should be limited to designated CMS-approved VPN or VDI solutions. Based on the designated VPN or VDI solution, configurations for firewall rules, Intrusion Detection and Prevention System policies, server policies, and active directory group policies as implemented in collaboration with AC control family requirements, will limit remote access.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrivileged commands and access\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe execution of privileged commands and access via remote access is restricted. Remote access for privileged commands and access should only be permitted if operational needs cannot otherwise be met via a direct connection in a secured access-controlled environment.\u003c/p\u003e\u003cp\u003eSystems should be configured to allow privileged user accounts to execute privileged commands to security-relevant information via remote access under special circumstances associated with the need to complete a task for critical operational needs. If a system opts to enable appropriate privileged commands via remote access, the rationale for the permission must be documented in the SSPP and approved via the CMS AO during the ATO approval process.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWireless access\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS monitors for unauthorized wireless access and prohibits the installation of wireless access points (WAP) in its systems. The Infrastructure and User Services Group (IUSG) are in charge of managing wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS information systems and prohibits the installation of WAP to systems unless explicitly authorized, in writing, by the CMS AO, i.e., the CMS CIO or the designated representative.\u003c/p\u003e\u003cp\u003eIf wireless access is authorized and approved by the AO during the ATO process, CMS establishes usage restrictions and configuration/connection requirements such as:\u003c/p\u003e\u003cul\u003e\u003cli\u003eFIPS 140-3 encryption protection is enabled\u003c/li\u003e\u003cli\u003eAccess points are placed in secure areas where physical access controls can be implemented, monitored, and audited\u003c/li\u003e\u003cli\u003eAccess points are shut down, i.e., powered off, when not in use (nights, weekends)\u003c/li\u003e\u003cli\u003eA stateful inspection firewall is implemented between the wireless network and the wired infrastructure; where a direct telecommunication wired connection is established\u003c/li\u003e\u003cli\u003eMedia Address Control (MAC) address authentication is utilized\u003c/li\u003e\u003cli\u003ePersonal firewalls are utilized on the endpoint device, e.g., laptop, and file sharing is disabled on all wireless clients\u003c/li\u003e\u003cli\u003eIntrusion detection agents are deployed on the wireless side of the firewall device\u003c/li\u003e\u003cli\u003eWireless activity is monitored and recorded, and the records are regularly reviewed\u003c/li\u003e\u003cli\u003eAdheres to \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Wireless-Acceptable-Use-Policy.pdf#search=cms%2520rules%2520of%2520behavior\"\u003eCMS Policy for Wireless Client Access\u003c/a\u003e and \u003ca href=\"https://www.hhs.gov/sites/default/files/standard_2009-0003_001s_-_ocio.DOC\"\u003eHHS Standard for IEEE 802.11 Wireless Local Area Network (WLAN)\u003c/a\u003e.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eRogue wireless devices, i.e., unauthorized WAPs, that are connected to the network can be detected by the wireless intrusion prevention system (WIPS). Any unauthorized WAP connected to the CMS internal network will be detected and locked out at the switch level (performing a port lock action on the switch IP address connection point) and then followed up as a potential security incident using the CMS Incident Response Process. For additional information on how to connect an approved wireless connection to CMS, please refer to the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Wireless-Network-Employee-Connection-Guide.pdf\"\u003eCMS Wireless Network Connection Guide\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthentication and encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems are protected against wireless networking capabilities by using authentication and the encryption of both users and devices. Wireless networking capabilities represent a significant potential vulnerability that can be exploited by adversaries.\u003c/p\u003e\u003cp\u003eThe CMS Baltimore Data Center Group (BDCG) manages the wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS systems and prohibits the installation of WAP devices to systems unless explicitly authorized, in writing, by the CMS AO, i.e., the CMS CIO or the designated representative. For more information on Authentication and Encryption, please refer to the System and Communications Protection (SC) and the Identification and Authentication (IA) Controls of the \u003cem\u003eCMS ARS\u003c/em\u003e.\u003c/p\u003e\u003cp\u003eAll wireless access points are configured to authenticate users and devices before access is granted. Also, all WLAN components use FIPS 140-3 approved cryptographic algorithms to protect the confidentiality and integrity of WLAN communications.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable wireless networking\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll wireless network capabilities embedded within CMS systems components must be disabled before issuance and deployment. Disabling all the wireless capabilities when not needed for essential CMS missions or functions can reduce susceptibility to threats by adversaries involving wireless technologies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRestrict configurations by users\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccess enforcement mechanisms are employed to restrict access to configure wireless networking capability only to selected and authorized users. Only CMS-approved and authorized users should be allowed to configure network capabilities. The responsibility of securing the CMS wireless network should rest in the hands of network administrators with system administrator (SYSADMIN) type accounts, that only allow SYSADMIN type commands to be performed under this type of SYSADMIN role.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing restrictions on access to wireless configurations.\u003c/p\u003e\u003col\u003e\u003cli\u003eCMS restricts access to wireless networking configurations only to the authorized role of a network administrator.\u003c/li\u003e\u003cli\u003eWireless networking capabilities are also confined within CMS boundaries.\u003c/li\u003e\u003c/ol\u003e\u003ch2\u003e\u003cstrong\u003eAntennas and transmission power levels\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS limits the unauthorized use of wireless communications outside of CMS-controlled boundaries. Radio antennas and transmission power levels must be calibrated to reduce the probability that usable signals can be intercepted by unauthorized users. Network traffic must be continuously monitored within CMS boundaries to detect and respond to intrusion and network misuse.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccess Control for mobile devices\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAll CMS-controlled mobile devices, including when such devices are outside of the CMS-controlled areas, must abide by the established configuration requirements, connection requirements, and implementation guidance in the CMS ARS when connected to the CMS environment.\u003c/p\u003e\u003cp\u003eCMS network administrators must set usage restrictions, configuration, and connection requirements for all mobile devices. The \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Mobile-Device-Guidance.pdf#search=CMS%2520Guidance%2520for%2520Government%2520Furnished%2520Mobile%2520Devices\"\u003eCMS Guidance for Government Furnished Mobile Devices\u003c/a\u003e provides information on the responsible use of CMS-issued mobile devices.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing access control requirements for mobile devices:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAll CMS-issued laptops utilize full disk encryption software that is FIPS 140-3 validated\u003c/li\u003e\u003cli\u003eCMS-procured removable storage media are configured for use by the contracted maintainer and use CMS-approved encryption for the storage of information\u003c/li\u003e\u003cli\u003eAny non-GFE equipment being connected internally to the network requires a fully signed \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eRules of Behavior for General Users\u003c/a\u003e form which details CMS' Operational Division (OpDiv) security responsibilities relative to the equipment being connected, along with prior approval from the CMS AO during the ATO process. The document also details the responsibilities the requester will fulfill or face possible disciplinary and/or non-disciplinary actions. Please refer to the HHS RoB, Section 6.3 Non-compliance for a list of potential adverse actions that may be taken against a user for non-compliance.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eGFE equipment may be connected remotely via VPN (using the established VPN for the Contractors' process). VPN authentication involves remote NAC checks that ensure the integrity of the system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFull device or container-based encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS-issued mobile devices must be encrypted using full device or container-based encryption mechanisms to protect the confidentiality and integrity of the data and information contained. Container-based encryption provides a more fine-grained approach to data and information encryption on mobile devices, including encrypting selected data structures such as files, records, or fields. Since mobile devices are more likely to be lost or stolen, sensitive information on a mobile device(s) is more vulnerable to unauthorized disclosures and encryption reduces this vulnerability.\u003c/p\u003e\u003cp\u003eAt CMS, FIPS 140-3 encryption mechanisms are used to protect the confidentiality and integrity of information on CMS-issued mobile devices. CMS utilizes media and port protection software to encrypt removable media endpoint devices.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eUse of external systems\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS employs mechanisms that prohibit the use of external devices to access the systems within the network without a formal approval process. CMS complies with the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e, which strictly prohibits the use of personal devices to conduct CMS-related business without written and approved authorization by the CMS AO under the ATO approval process.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for the use of external information systems control requirements:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS prohibits the use of external systems without explicit written approval from the AO.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS does not allow the use of external systems that are not approved and do not meet CMS security requirements. If approval is granted, the recipient verifies the terms and conditions, ensures the required controls are implemented for the identified FIPS 199 system categorization to mitigate the associated risks, limits user access accordingly, and documents the control implementations in the SSPP.\u003c/li\u003e\u003cli\u003eAccess to PII from external systems (including, but not limited to, personally owned information systems/devices) is reinforced by a binding agreement to terms and conditions of the CMS’s privacy requirements to ensure awareness and accountability of both parties under the Interconnection Security Agreement approval process.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eLimits on authorized use\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS ensures that only authorized users are permitted to use external systems to access its systems, and these systems must have the necessary security configurations implemented before access is granted. These necessary security requirements are implemented and the CMS access control policies regarding the use of external systems are enforced.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for limiting the authorized use of external information systems:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS does not permit the use of external systems that are not approved and do not meet the CMS security requirements for accessing CMS systems per the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eExternal systems can only access CMS systems using approved VPN or VDI access and firewall/security verification software, which must be installed on each machine. This applies to federal employees and contractor personnel utilizing CMS GFE (laptop or desktop) only or approved corporate-issued computers per the contract.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePortable storage devices — restricted use\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS limits the use of its controlled-portable storage devices in external systems. Conditions of use or restrictions on these devices should be documented and configured by network administrators.\u003c/p\u003e\u003cp\u003eCMS has configured CMS-issued portable and mobile devices to meet federal requirements. CMS has provided several control implementations that support and manage how its information is used within portable storage devices. These include a policy to incorporate a methodology for protecting the information and the rules used to manage the information while in transit. For more information, review the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/StorageDeviceandEncryption.aspx\"\u003eCMS Storage Device and Encryption\u003c/a\u003e website.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eInformation sharing\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eInformation sharing control puts restrictions on CMS-sensitive information and CUI, such as personally identifiable information (PII), contract-sensitive information, proprietary information, and classified information related to special access programs or compartments, based on a formal or administrative risk-based determination. Depending on the information-sharing circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program/compartment.\u003c/p\u003e\u003cp\u003eGuidance for information sharing between CMS and other organizations is specified in the CMS Privacy Handbook. The document specifies the requirements for information sharing in the following documents:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-interconnection-security-agreement-isa\"\u003eInterconnection Security Agreement (ISA):\u003c/a\u003e System interconnections are defined within CFACTS and require a supporting “signed” ISA between CMS and non-CMS organizations as part of the SSP/ATO process.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-memorandum-understanding-mou\"\u003eMemorandum of Understanding (MOU):\u003c/a\u003e Defines the relationship of two or more federal partners that enter into a joint project or collaboration in which they each contribute their resources.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-data-use-agreement-dua\"\u003eData Use Agreement (DUA):\u003c/a\u003e 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.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-information-exchange-agreement-iea\"\u003eInformation Exchange Agreements (IEA):\u003c/a\u003e Is needed when Personally Identifiable Information (PII) needs to be shared externally, and that will not have an adverse impact on the beneficiary.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-computer-matching-agreement-cma\"\u003eComputer Matching Agreements (CMA):\u003c/a\u003e A written agreement establishing the conditions, safeguards, and procedures under which a federal agency agrees to disclose data with another federal or state agency when there is a computerized comparison of two or more automated Systems of Records (SORs).\u003c/li\u003e\u003cli\u003eOther forms of documented agreements required for different situations.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor additional guidance related to the above agreements and documents, please review the Privacy Handbook. The ISSO is responsible for developing and managing any agreement utilized for information sharing and should coordinate with the appropriate Data Guardian and Privacy Advisor.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePublicly accessible content\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePer applicable laws, executive orders, directives, policies, regulations, standards, and guidelines, the general public is not authorized to access non-public information, such as information protected under the Privacy Act information (e.g., PII/PHI), CMS sensitive information (e.g., data with a federal information classification standard, For Official Use Only [FOUO], or Controlled Unclassified Information [CUI]), and CMS proprietary information (e.g., proprietary acquisition data). This control addresses systems that are controlled by CMS and are accessible to the public, typically without requiring identification or authentication.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for adhering to requirements for publicly accessible content:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNetwork Connections\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eCMS Website Owners/Administrators are charged with limiting the connections to publicly available CMS websites and web services to approved secure protocols and adhering to Hypertext Transfer Protocol (HTTP) Strict Transport Security (HSTS) practices.\u003c/p\u003e\u003cul\u003e\u003cli\u003eAlthough general public access to the CMS internal network is not allowed, CMS websites are accessible by the public and protected by several Private Internet Exchange (PIX) firewalls\u003c/li\u003e\u003cli\u003eOutbound internet connections from CMS users are protected by Application Intelligence (NG AI) firewalls.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003ePublic Content\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CMS system personnel should reach out to the CMS Information Security and Privacy Group (ISPG) to review the proposed content of information on a publicly accessible system (including a public website) before posting or publication to ensure that nonpublic information is not included.\u003c/li\u003e\u003cli\u003eThe frequency of the review will be commensurate with the frequency information is posted. Whenever new information is being considered to be uploaded to a site, it should trigger a review process to ascertain it complies with CMS policy.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe system should consult the ISPG for clarification as to if the information is suitable for public accessibility and publication.\u003c/p\u003e"])</script><script>self.__next_f.push([1,"1d:T12d87,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccess is the ability to make use of any system resource. \u003ca href=\"https://csrc.nist.gov/glossary/term/access_control\"\u003eAccess Control (AC)\u003c/a\u003e is the process of granting or denying specific requests to:\u003c/p\u003e\u003col\u003e\u003cli\u003eObtain and use the information and related information processing services\u003c/li\u003e\u003cli\u003eEnter specific physical facilities (e.g., federal buildings, military establishments, border crossing entrances)\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAccess Control entails the regulation of who or what is allowed to access resources in an information system or network. As an important aspect of information security, access control helps to prevent unauthorized access to systems, services, and data.\u003c/p\u003e\u003cp\u003eAccess Control focuses on how the organization must limit system access to authorized users, to processes acting on behalf of authorized users, or to devices (including other systems), and how the organization must limit the types of transactions and functions that authorized users are permitted to conduct. Access Control can be implemented in various ways, including but not limited to the use of passwords, biometric authentication, and permissions assigned to specific users or groups. The level of access granted to an individual or a system may vary depending on their roles or responsibilities within an organization.\u003c/p\u003e\u003cp\u003eAccess control, a selective restriction of access to systems or data, consists of two main components: authentication and authorization. Authentication is the verification of the identity of a user, process, or device, and it is often the prerequisite to allowing access to resources in a system. Authorization, on the other hand, is the process of granting or denying specific requests:\u003c/p\u003e\u003col\u003e\u003cli\u003eFor obtaining and using information and related information processing services\u003c/li\u003e\u003cli\u003eTo enter specific physical facilities (e.g., Federal buildings, military establishments, and border crossing entrances)\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAuthentication and authorization are concerned with determining the allowed activities of legitimate users and mediating every attempt to access the resources in the system or an authorized entrance into a federal facility. The access must be based on the principle of \u003ca href=\"https://csrc.nist.gov/glossary/term/least_privilege\"\u003eleast privilege\u003c/a\u003e. In some systems, complete access is granted after successful authentication of the user, but most systems require more sophisticated and complex controls. In addition to the authentication mechanism (such as a password or token), access control is concerned with how authorizations are structured. In some cases, authorization may mirror the structure of the organization, while in others it may be based on the sensitivity level of various information resources with the roles and responsibilities of the user accessing those resources.\u003c/p\u003e\u003cp\u003eThe requirements for the use or the prohibitions against the use of various system resources also vary from one system to another. For example, some information may be available to all users, some may be available to specific groups or divisions, and some may be accessible to only a few individuals or groups across the agency. While users must have access to the specific information needed to perform their jobs, denial of access to non-job-related information may be enforced. It may also be important to control the type of access that is permitted (e.g., the ability for an average user to execute, but not change, system programs). These various types of access restrictions enforce policy, and ensure that unauthorized actions are not permitted.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePurpose\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe purpose of this document is to serve as a guide for managing access by providing background information and an overview of access control policies, procedures, and processes for restricted resources and data across the Centers for Medicare \u0026amp; Medicaid (CMS).\u003c/p\u003e\u003cp\u003eTo implement the security requirements for the Access Control (AC) family, as identified in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST Special Publication (SP) 800-53 Revision 5 \u003cem\u003eSecurity and Privacy Controls for Information Systems and Organizations\u003c/em\u003e\u003c/a\u003e, \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p\"\u003eHHS \u003cem\u003ePolicy for Information Security and Privacy Protection (IS2P)\u003c/em\u003e\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS\u003cem\u003e Information Systems Security and Privacy Policy (IS2P2)\u003c/em\u003e\u003c/a\u003e\u003cem\u003e, \u003c/em\u003eand the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS\u003cem\u003e Acceptable Risk Safeguards (ARS)\u003c/em\u003e\u003c/a\u003e\u003cem\u003e, \u003c/em\u003ethis manual also defines the rules around access to resources, and how access is allowed or denied by ensuring that only authorized personnel are granted access to critical information and resources while maintaining the security and confidentiality of sensitive information and Controlled Unclassified Information (CUI).\u003c/p\u003e\u003cp\u003eThis document is also intended to provide a consistent and secure approach to managing access to information and systems by serving as a reference for all CMS federal employees, contractors, and other authorized personnel. By following the processes outlined in this manual, CMS can minimize the risk of security breaches, data theft, and unauthorized access, thereby safeguarding the confidentiality, integrity, and availability of its systems and protecting the stakeholders.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eApplicability and scope\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eFederal information systems are required to incorporate information security controls to protect the systems supporting their operations and missions. CMS is required to ensure the adequate protection of its information systems and must meet a minimum level of information security.\u003c/p\u003e\u003cp\u003eFurther, the use of controls is mandatory for federal information systems in accordance with \u003ca href=\"http://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf\"\u003eOffice of Management and Budget (OMB) Circular A-130\u003c/a\u003e, and the provisions of the Federal Information Security Modernization Act \u003ca href=\"https://www.congress.gov/bill/113th-congress/senate-bill/2521\"\u003e[FISMA]\u003c/a\u003e of 2014, which requires the implementation of minimum controls to protect federal information and information systems. This program manual, along with the CMS \u003cem\u003eARS\u003c/em\u003e, satisfies the requirements of FISMA, and OMB Policies, among other laws, regulations, and policies, and will improve communication among stakeholders on how access to information systems or networks within the agency is managed.\u003c/p\u003e\u003cp\u003eTo this, the program manual applies to all CMS personnel or entities:\u003c/p\u003e\u003cul\u003e\u003cli\u003eConducting business for CMS\u003c/li\u003e\u003cli\u003eCollecting or maintaining information for CMS\u003c/li\u003e\u003cli\u003eUsing or operating information systems on behalf of CMS, whether directly or through contractual relationships.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe lists of CMS personnel or entities include, but are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eOrganizational components, centers, or offices\u003c/li\u003e\u003cli\u003eFederal employees, contractor personnel, interns, or other non-government employees operating on behalf of CMS.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis document is also applicable to all Information Technology (IT) resources, including network and computer hardware, software and applications, mobile devices, and telecommunication systems owned or operated by (or on behalf of) CMS.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRoles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePlease refer to the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2#roles-and-responsibilities\"\u003e\u003cem\u003eCMS IS2P2\u003c/em\u003e: Roles and Responsibilities\u003c/a\u003e and \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p#7.33\"\u003e\u003cem\u003eHHS Policy for Information Security and Privacy Protection (IS2P)\u003c/em\u003e Section 7 Roles and Responsibilities\u003c/a\u003e for the specific roles of CMS staff positions, contractors, or any entity operating on behalf of CMS. Further, the responsibilities related to the specific role(s) in the \u003cem\u003eCMS IS2P2:\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eSupervisors\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cem\u003eSystem/Network Administrators\u003c/em\u003e\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eor \u003cem\u003eHHS IS2P:\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eSection 7.33 (System Administrator)\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cem\u003eSection 7.37 (Supervisor)\u003c/em\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003efor roles supporting the AC control family are as follows:\u003c/p\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eSupervisors\u0026nbsp;\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eAuthorize and (or) approve the creation of new user accounts.\u003c/li\u003e\u003cli\u003eEnsure the access role is based on the principle of least privilege to ensure the user only has the authorized access rights to systems and information that is only enough to perform the duties described within their job description.\u003c/li\u003e\u003cli\u003eEnsure the user account is disabled and (or) removed when the employee separates from the position and no longer requires access. \u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eSystem Administrators [ADMIN]\u003c/strong\u003e\u003c/em\u003e\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e\u0026nbsp;\u003cbr\u003e(e.g., database administrators, network administrators, web administrators, and application administrators)\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsure that when performing administrator-type functions (e.g., as a privileged user), the ADMIN is logged on their privileged account only and their responsibilities are established to perform just those privileged functions with defined privileged commands and privileged processes.\u003c/li\u003e\u003cli\u003eFollow the established CMS system security protocols and processes as established in the \u003ca href=\"https://security.cms.gov/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e for onboarding new employees for new account creation, once the individual has completed all pre-required onboarding activities before account issuance (e.g., filing out required application for access forms and receiving the appropriate approvals, completing required security awareness and role-based training, completing any person proofing requirements, obtaining a required CMS-approved hard token credentials [PIV card, RSA token, etc.] for multi-factor authentication, etc.) or for any user requiring a modification to their account security credentials.\u003c/li\u003e\u003cli\u003eEnsure the account security credential(s) are issued to the appropriate authorized individual user.\u003c/li\u003e\u003cli\u003eEnsure all the security-related activities required are met to ensure the secure establishment and management of user accounts. (Refer to Account Management below).\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eCMS Access Control services and practices\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis section describes an overview of some of the CMS services and practices that assist in the discussion and the implementation of the AC family as outlined in the \u003cem\u003eCMS ARS \u003c/em\u003eand the \u003cem\u003eCMS IS2P2. \u003c/em\u003eThe information in this section provides some important considerations for implementing Access Control based on the mission and business requirements of CMS, its operational environments, and the assessments of organizational and system risks. The additional information contained in this section also explains the purpose of the control and the mechanisms to meet the control requirements.\u003c/p\u003e\u003cp\u003ePlease consult the CMS \u003cem\u003eARS \u003c/em\u003efor specific procedures.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccount management\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccount Management control is required to establish the requirements for managing CMS systems and user accounts throughout the account lifecycle. The Office of Information Technology (OIT) implements mechanisms that are responsible for all account management-related activities. These mechanisms help to ensure CMS personnel or entities have secure, authorized access to CMS business applications. The primary functions of an account management feature are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eRegistration\u003c/li\u003e\u003cli\u003eAuthentication\u003c/li\u003e\u003cli\u003eAuthorization\u003c/li\u003e\u003cli\u003eIdentity and User Account Lifecycle Management.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe account control mechanisms are also required to authorize and monitor the use of guest or anonymous accounts, and remove, disable, or otherwise secure unnecessary accounts.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for Account Management:\u003c/p\u003e\u003col\u003e\u003cli\u003eCMS information systems must have a documented Access Control procedure to document account life cycle activities. A description of all authorized system users, account access privileges, and other applicable account attributes must be documented.\u003c/li\u003e\u003cli\u003eAccount creation, changes, disabling, and retiring are requested using the channels documented in the applicable access control procedure or the system security and privacy plan.\u003c/li\u003e\u003cli\u003eThe following requirements are adhered to before creating, enabling, modifying, disabling, or removing accounts:\u003c/li\u003e\u003c/ol\u003e\u003cul\u003e\u003cli\u003eValid access authorization\u003c/li\u003e\u003cli\u003eIntended system usage\u003c/li\u003e\u003cli\u003eSatisfactory completion of mandatory training requirements (Security Awareness Training [SAT] in the Awareness and Training [AT] family of controls [and annually thereafter]; pre-access and role-based training within the prescribed timeframe), acknowledgment of \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eRules of Behavior for General Users\u003c/a\u003e, and signed request forms.\u003c/li\u003e\u003cli\u003eA valid justification must be supplied if access rights are above what is minimally necessary to perform the duties of the job.\u003c/li\u003e\u003cli\u003eList of functions required to perform job duties\u003c/li\u003e\u003cli\u003eAuthorization and approval from applicable information account managers as described in the system security and privacy plan.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp; \u0026nbsp;4. The Primary Information System Security Officer (P-ISSO) (or alternate) is tasked with:\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsuring access control policies and procedures are followed.\u003c/li\u003e\u003cli\u003eAuditing account management activities to ensure compliance.\u003c/li\u003e\u003cli\u003eReviewing access privileges to ensure all users have justifiable permissions.\u003c/li\u003e\u003cli\u003eEnforce account management lifecycle activities.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe \u003cem\u003eCMS ARS\u003c/em\u003e requires removing or disabling default user accounts, renaming active default user accounts, implementing a centralized control of user access administrator functions, regulating and defining the access provided to contractors, searchable automated account management results by \u003ca href=\"https://security.cms.gov/learn/cms-cybersecurity-integration-center-ccic\"\u003eCMS Cybersecurity Integration Center (CCIC)\u003c/a\u003e, and all raw security information/results from relevant automated tools must be available in an unaltered format to the CCIC.\u003c/p\u003e\u003cp\u003eAccount managers must be notified when a CMS system user is terminated or transferred, and the user’s associated account removed, disabled, revoked, or otherwise secured within a Mission/Business/System-defined timeframe, and not to exceed 30 days from the date of termination or transfer. Account managers must also be notified when there are changes in the user's system usage or need to know.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated system account management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAutomated System Account Management is required to manage, create, enable, modify, disable, revoked, retire, and remove CMS system account(s) when a user is terminated or transferred. CMS access control tools leverage the use of emails or text messaging to notify managers and users of account lifecycle events. These tools have automated capabilities to review user account activities and usage and report atypical behavior using email notifications.\u003c/p\u003e\u003cp\u003eCMS system administrators must be notified via automated email whenever a user account lifecycle event has occurred. Automated email mechanisms must be in place to support the management of system accounts. Additionally, users are emailed prior to password expiration and are allowed to make the necessary password changes.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated temporary and emergency account management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAutomated temporary and emergency account management is required to automatically remove or disable the access rights of temporary or emergency accounts after a predefined period after activation rather than at the convenience of the system administrator. Automatic removal or disabling of accounts provides a more consistent implementation.\u003c/p\u003e\u003cp\u003eCMS temporary and emergency accounts are managed in accordance with the system’s account management procedures or the security and privacy plan. These accounts are provisioned only when necessary and authorized, and they must be established with a fixed duration based on the need not to exceed the CMS parameter.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable accounts\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to automatically disable accounts that are expired, no longer associated with a user or individual, violate CMS policy, or have been inactive for a predefined period.\u0026nbsp;\u003c/p\u003e\u003cp\u003eFor an inactive account, a scheduled task reconciles the Last Login Date from the system database and locks the user account if the period reached its expiration date. Users who have not logged in during the inactivity period are marked as inactive and their accounts locked. The user will be notified at the next logon attempt that their account has been locked and can make use of the self-unlock feature or an IT Service Desk request for a user account reset.\u003c/p\u003e\u003cp\u003eAll these processes support the concepts of least privilege and least functionality that reduce the attack surface of systems.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated audit actions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS access control systems are required to utilize the capability to automatically produce event logs for system administrators to review for administrative actions. These may include account creation, modification, enabling, disabling, and removal actions for audit record review, analysis, and reporting. In addition to any other actions defined in the applicable system security and privacy plan.\u003c/p\u003e\u003cp\u003eCMS systems must be configured to log and audit the following account lifecycle events:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCreation\u003c/li\u003e\u003cli\u003eEnabling\u003c/li\u003e\u003cli\u003eModification\u003c/li\u003e\u003cli\u003eDisabling and;\u003c/li\u003e\u003cli\u003eRemoval (Retirement and Termination).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNotifications for these relevant and significant events are sent to the system administrators or managers as documented in the applicable security and privacy plan. Account actions in Active Directory (AD) are logged and exported to a Security Incident and Event Management (SIEM) tool where custom alerts are created, which notify appropriate individuals of these activities.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eInactivity logout\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eInactivity logout after a defined period reduces the risks of unauthorized access to CMS systems. This is accomplished by setting a lock on the system after 90 minutes of inactivity to prevent users from obtaining information from the display device while an authorized user is actively logged into the system or application. Users are also encouraged to lock their systems when leaving the vicinity and are required to log out at the end of a normal work period.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eUsage conditions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eClearly defined account usage conditions establish and describe the specific conditions or circumstances under which CMS system accounts can be used. These conditions help enforce the principle of least privilege, increase user accountability, and enable effective account monitoring. CMS defines these usage conditions for particular system accounts as necessary to provide adequate information protections and configure systems to enforce them.\u003c/p\u003e\u003cp\u003eThe following details the usage conditions that are set and must be met before access is granted to CMS systems:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS requires all users who have been provisioned a User ID to complete an initial and annual certification of access needs, as well as the security Computer Based Training (CBT) course. Access is revoked for users who have not complied with these requirements annually.\u003c/li\u003e\u003cli\u003eCMS users are required to accept the government warning displayed on the CMS warning banner before accessing CMS Government-Furnished Equipments (GFEs), CMS VPN connections, or CMS Virtual Desktop Infrastructure (VDI) using CITRIX Workspace connections. This warning banner is an acknowledgment of monitoring and usage restrictions.\u003c/li\u003e\u003cli\u003eAll users must complete all CMS system-related documentation including access request forms, \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eHHS rules of behavior\u003c/a\u003e for General Users, and any additional training required based on individuals with Significant Information Security Responsibilities (SISR), e.g., Role Based Training (RBT) for any user identified with significant information security and privacy responsibilities, as required in the applicable system security and privacy plan.\u003c/li\u003e\u003cli\u003eCMS users are prohibited from accessing systems from non-US locations during foreign travels without first obtaining official leadership approval. For more information on the approval process, review Chapter 10: Foreign Travel of the \u003cem\u003eCMS Physical Security Handbook\u003c/em\u003e.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAccount monitoring for atypical usage\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe administrative monitoring of activities associated with CMS system accounts is established to determine unusual and malicious use. CMS security teams monitor accounts for atypical usage that may include assessing systems at unusual days and times or from locations that are not consistent with the normal usage patterns of individuals, and for unusual information transfer volumes. Monitoring may also reveal rogue behavior by individuals or an attack in progress. There is coordination between CMS systems and the security teams through the CCIC to monitor system accounts and their usage and report to CMS incident response teams.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for monitoring user accounts for atypical usage.\u003c/p\u003e\u003cp\u003eCMS employs several security appliances and devices to assist with the ongoing monitoring of systems, as well as related system accounts, for atypical usage.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eFirewalls:\u003c/strong\u003e Network- and host-based firewalls are used to monitor traffic and generate daily reports covering the last 24 hours of activity.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity Information and Event Management (SIEM):\u003c/strong\u003e This solution is used to review logs generated from applications, databases, and servers for analysis by CMS security teams.\u003c/p\u003e\u003cp\u003eIn accordance with CMS information system Incident Response Plans, CMS CCIC should be notified immediately of potential security incidents upon discovery.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable accounts for high-risk individuals\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eDisabling the accounts for high-risk individuals reduces the risks posed by an insider threat that could adversely impact CMS IT assets, environment, operations, and individuals. Users who pose significant security or privacy risks include individuals for whom reliable evidence indicates either intention to use authorized access to a system to cause harm or through whom adversaries will cause harm.\u003c/p\u003e\u003cp\u003eDisabling accounts of high-risk individuals is a minimum requirement for the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior\u003c/a\u003e for Use of Information and IT Resources because of the possibility of abusing access privileges to sensitive information and CUI, including information protected under the Privacy Act.\u003c/p\u003e\u003cp\u003eAccount management activities must be expedited for the revocation of access for high-risk user accounts. Notification is sent to the appropriate security personnel as documented in the system security and privacy plan using the appropriate channels (email or phone). After being notified, the account must be disabled within a reasonable time frame not to exceed the CMS-established parameter from the time the high-risk account is identified.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccess enforcement\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccess control policies and the associated access enforcement mechanisms are employed to automatically control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the systems. These access control mechanisms must restrict access to any sensitive information, CUI or personally identifiable information (PII) and protected health information (PHI).\u003c/p\u003e\u003cp\u003eCMS systems are configured to enforce approved authorizations for logical access to information and system resources that support its mission and business functions, in accordance with applicable access control policies.\u003c/p\u003e\u003cp\u003eFurther, access enforcement mechanisms can be employed at the application and service level to provide increased information security and privacy. Assigned privileges and rules are used to allow logical access to systems, applications, and databases. These privileges are assigned during the account creation and modification account lifecycle.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eControlled release\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eControlled release of information ensures systems implement technical or procedural means to validate the controls implemented by any external systems before releasing information to them. All external systems or entities (i.e., departments, agencies, or commercial entities not managed by CMS) must provide controls that are commensurate with those implemented by CMS to protect the released information. The means used to determine the adequacy of the controls provided by the recipient systems may include conducting periodic assessments (inspections/tests), establishing agreements between CMS and external entities, or some other process. The adequacy of the implemented controls on those external systems ensures a consistent adjudication of the security and privacy policy that protects the information and individuals’ privacy.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eIndividual access\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS allow access to individuals that enable them to review personally identifiable information about them collected via legislative mandates and healthcare programs. Access helps individuals to develop an understanding of how their personally identifiable information is processed, handled, and disseminated to ensure their data is accurate and secure. Access mechanisms can include request forms and application interfaces. As stipulated by the Privacy Act, individual record access procedures are contained in systems of record notices (SORN) and the SORNs published on the Federal Register and CMS/HHS websites.\u003c/p\u003e\u003cp\u003eHowever, individual access to certain types of records contained in the HHS Exempt Systems of Records may be exempt, in full or in part, from certain requirements of the Privacy Act, based on rulemakings promulgated under subsection (j) or (k) of the Privacy Act (5 U.S.C. § 552a(j), (k)). Note that 5 U.S.C §. 552a(d)(5) excludes material compiled in reasonable anticipation of a civil action or proceeding from the Privacy Act's access requirement, in all systems of records, without the need for rulemaking.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eInformation flow enforcement\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eInformation flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) without regard to subsequent access to that information. Flow control restrictions may include blocking external traffic that claims to be from within CMS, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from CMS's internal web proxy server, and limiting information transfers between CMS and other external entities based on data structures and content.\u003c/p\u003e\u003cp\u003eTransferring information between CMS and other external entities may require an agreement specifying how the information flow is enforced using \u003ca href=\"https://security.cms.gov/learn/cms-interconnection-security-agreement-isa\"\u003einterconnection security agreements (ISA)\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cms-information-exchange-agreement-iea\"\u003einformation exchange security agreements\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cms-memorandum-understanding-mou\"\u003ememoranda of understanding or agreement (MOU/MOA)\u003c/a\u003e, service level agreements (SLA), or other exchange agreements (as defined in the applicable security and privacy plans).\u003c/p\u003e\u003cp\u003eInformation flow enforcement may also include prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regarding mechanisms to reassign security or privacy attributes and labels.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing information flow enforcement.\u003c/p\u003e\u003cp\u003eCMS uses a variety of methods and applications to enforce information flow with systems and between interconnected systems.\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CMS access control systems are configured to enforce approved authorizations within CMS information systems and other interconnections. For more information on interconnections and information sharing, please review AC-21 in the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e\u003cem\u003e.\u003c/em\u003e\u003c/li\u003e\u003cli\u003eVirtual Local Area Networks (VLANs) are used to provide environment and zone separation with firewall device control between each interconnected VLAN. Firewall rules are then configured to restrict information flows to only authorized users.\u003c/li\u003e\u003cli\u003eInterconnection between different server types within the CMS information system environment is controlled by network devices including firewalls. Rules are set up to allow traffic to authorized destination internet protocol (IP) addresses only.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eFlow control of encrypted information\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to prevent encrypted information from bypassing information flow control mechanisms by either blocking the flow of the encrypted information or terminating communications sessions that attempt to pass encrypted information. Flow control mechanisms may include content checking, security policy filters, and data type identifiers. The term encryption is extended to cover encoded data that are not recognized by the filtering mechanisms.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSeparation of duties\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSeparation of duties for CMS’s accounts is enforced to address the potential for abuse of authorized privileges and reduces the risk of malevolent activity without collusion. Each individual`s responsibilities and privileges within CMS`s environment are defined in a way that inhibits intentional or inadvertent unauthorized activity. Through the use of job codes, roles, and access rights, the workflows for authorization are separated in the CMS environment. A job code is a role that grants a group of users, access to defined resources. All ISSOs are required to ensure that these requirements are implemented effectively and meet the minimum control standards within the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e in their respective systems during authorization.\u003c/p\u003e\u003cp\u003eFurther, implementing separation of duties control reduces the risk of inappropriate access to CMS's sensitive information and CUI (e.g., separating employees that perform security and breach investigations from routine mission and business functions).\u003c/p\u003e\u003cp\u003eCMS Business owners control the access to their respective CMS systems. They create privileges that limit an individual's account access only to those systems for which there is a business need. Access rights are established while considering the separation of duties based on the following factors:\u003c/p\u003e\u003cul\u003e\u003cli\u003eDividing mission functions and information system support functions among different individuals and/or roles.\u003c/li\u003e\u003cli\u003eConducting information system support functions with different individuals (e.g., system management, programming, configuration management, quality assurance and testing, and network security).\u003c/li\u003e\u003cli\u003eEnsuring security personnel administering access control functions do not also administer approval or audit functions.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eLeast privilege\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS employs the principle of least privilege to ensure that its information system accounts are provisioned at privilege levels no higher than necessary to accomplish the mission/business functions. In other words, the system access privileges are only enough, i.e., at a minimum, for a user to perform their assigned duties as prescribed in their job descriptions. CMS systems are configured to prevent non-privileged accounts from having access to security or audit-related settings and controls. It is strictly prohibited to knowingly exceed authorized access according to the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eAt CMS, role-based access control is used to restrict access to system functions only to designated individuals. The restrictions must be based on the minimum necessary access required to complete specific system activities. These restrictions must be included in system-specific documentation, and are necessary to ensure that only authorized users are permitted access to files, directories, drives, workstations, servers, network shares, ports, protocols, and services that are expressly required for the performance of their job duties. Unnecessary access rights associated with services that are not required for the operation of the system should be disabled.\u003c/p\u003e\u003cp\u003eThe concept of least privilege aligns with the notion of limiting access to CMS's sensitive information and CUI to those individuals with a documented need to know in the performance of their job duties.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthorize access to security functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eSecurity functions in CMS are limited only to authorized personnel. Security functions include but are not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), configuring settings for events to be audited, and establishing intrusion detection parameters.\u003c/p\u003e\u003cp\u003eCMS personnel classified as privileged users, according to the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS \u003cem\u003eIS2P2\u003c/em\u003e\u003c/a\u003e, are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe following details the CMS-specific process for authorizing access to security functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAccess is granted based on the privileged role and approved job codes, with privileged functions restricted to individuals with administrative or security functionality requirements.\u003c/li\u003e\u003cli\u003eThe privileged account is restricted to privileged functions only and cannot be used to perform normal user (i.e., non-privileged accounts) functions concurrently.\u003c/li\u003e\u003cli\u003eApproved servers may use RBAC which is implemented using Active Directory (AD) group memberships. Non-privileged accounts have no access to servers.\u003c/li\u003e\u003cli\u003eSystem configurations and parameters are by group policy (GPO).\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eNon-privileged access for non-security functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe implementation of non-privileged access for nonsecurity functions limits security exposure or incidents that might occur when users perform operations from within privileged accounts or roles. CMS-privileged accounts or roles must be used only when necessary to perform system administration and security duties. Also, CMS systems must be configured to prevent non-privileged users from executing privileged functions.\u003c/p\u003e\u003cp\u003eCMS-privileged users with access to security functions are provisioned with and required to use their non-privileged accounts to perform duties that do not require that level of access. The separation of privileged and non-privileged accounts also prevents unintended or unauthorized loss, modification, or exposure. For example, a System Administrator (SYSADMIN) would have a separate account to perform SYSADMIN functions, and a typical USER account to perform normal user functions such as email, application access [Word Documents, Spreadsheets, Presentations, etc.], etc. The SYSADMIN cannot perform SYSADMIN functions under the typical USER account or role.\u003c/p\u003e\u003cp\u003eIn addition, the typical USER account or role cannot perform SYSADMIN-type functions such as administration/ management of the following: operating systems, network operations (telecommunications devices, firewalls, DMZ, servers, database administration, etc.), application servers, database servers, etc. In other words, any operation that would require Operating System (OS), ADMIN, or root-level access to perform ADMIN-type services or operations.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNetwork access to privileged commands\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS restricts the ability to perform privileged commands across the network connection as opposed to the local access on its systems. CMS limits network access to activities requiring elevated privileges to situations where there is a compelling operational need. For example, a compelling operational need may include routine administration (management) of remote security and infrastructure devices across a dedicated management network (see the \u003cem\u003eCMS Technical Reference Architecture [TRA]\u003c/em\u003e for additional information).\u003c/p\u003e\u003cp\u003eNetwork access to privileged commands is limited to specific roles listed as privileged users in \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p\"\u003e\u003cem\u003eCMS IS2P2\u003c/em\u003e\u003c/a\u003e. These roles are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators\u0026nbsp;\u003c/li\u003e\u003cli\u003eAdditional roles as documented in the System Security and Privacy Plan (SSPP).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS personnel are approved for such access by requesting the necessary roles or privileges. The process of requesting and approving these roles or privileges (as documented in the system security and privacy plan) acts as a control to ensure the privilege is being assigned to the right user.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrivileged accounts\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS limits who is authorized to perform administrative or security functions on its systems. These functions may include configuring access permissions, setting audit logs, and performing system management functions. This level of access needs to be limited because it further protects sensitive information and CUI from being comprised by reducing the number of individuals who possess unnecessary high privileges.\u003c/p\u003e\u003cp\u003ePrivileged accounts are limited only to specific roles that require the performance of privileged functions in the CMS environment. These roles are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators\u0026nbsp;\u003c/li\u003e\u003cli\u003eAdditional roles as documented in the SSPP.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS personnel are approved for such access through the appropriate account privileges. The process of requesting and approving these account privileges (as documented in the SSPP) acts as a control to ensure the privilege is being assigned to the right user.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eReview of user privileges\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIn CMS, certain assigned user privileges may change over time to reflect changes in the mission and business functions, environments of operation, technologies, or threats. A periodic review of all assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid. If the need cannot be revalidated, appropriate corrective actions must be taken to address it.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eLog use of privileged functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eLog the use of all privileged functions to ensure that there is accountability for all CMS system accounts with privileged functions because of the elevated permissions to access, and grant access, to sensitive information and CUI.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for logging the use of privileged functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS systems audit the use of privileged functions via logging user accounts that have the right to conduct privileged functions only on the system.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe audit logs must include a user account trail of privileged commands executed intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts.\u003c/li\u003e\u003cli\u003eThese logs are then audited and reviewed using a SIEM tool.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eProhibit non-privileged users from executing privileged functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eProhibit non-privileged users from executing privileged functions so that appropriate individuals have access to privileged functions only based on their roles and responsibilities. Non-privileged users may not have the same level of trust as privileged users. Privileged users have access beyond that of a non-privileged user, and as such, may have a greater ability to access sensitive information and CUI. Privileged accounts typically may have root-level access to the system at the operating system (OS) level and therefore “keys to the kingdom” level of access to all components or services of that system. For this reason, systems must have the ability to trace (audit) the actions of the user who initiated them and what actions were taken.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe assignment of privileged functions to user accounts should be based on the role and the level of responsibility of the user, while still accounting for the principle of least privilege. Privileged functions are assigned to a user account through approved roles or privileges and the approval process acts as a safeguard to ensure access is being provisioned to the right user, who have been appropriately authorized for the escalated privilege.\u0026nbsp;\u003c/p\u003e\u003cp\u003eUsers' accounts are set up to allow only the necessary functions authorized, thereby enforcing the principle of least privilege.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eUnsuccessful logon attempts\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded counteracts denial of service attacks and ensures that the user account is accessed only by the owner of that account. Automatic account lockouts are initiated by systems and are usually temporary and automatically released after a predetermined period as established by the CMS system administrators.\u003c/p\u003e\u003cp\u003eThe implementation standards contained in the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e are determined by the system’s risk categorization as stated below:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHigh:\u003c/strong\u003e Configure the information system to lock out the user account automatically after three (3) invalid login attempts during a 120-minute time window. Require the lockout to persist until released by an administrator.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eModerate:\u003c/strong\u003e Configure the information system to lock out the user account automatically after five (5) invalid login attempts during a 120-minute time window. Require the lockout to persist for a minimum of one (1) hour.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eLow:\u003c/strong\u003e Configure the information system to disable access for at least fifteen (15) minutes after five (5) invalid login attempts during a 120-minute time window.\u003c/p\u003e\u003cp\u003eCMS users will experience a lockout if they reach the maximum number of invalid login attempts. Users will be locked out indefinitely and must contact the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/Request%2520IT%2520Service.aspx\"\u003eCMS IT Service Desk\u003c/a\u003e or their system administrator to request their account to be unlocked.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSystem use notification\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS systems are configured to display an approved notification to be accepted by users before login. This notification provides appropriate security and privacy notifications as well as terms of use of the system. All CMS information systems are configured to display a system-use notification message before granting access. This is commonly referred to as a “System Warning Banner”.\u0026nbsp;\u003c/p\u003e\u003cp\u003eHHS has an established language approved for use as defined in the \u003cem\u003eCMS ARS AC-08 System Use Notification \u003c/em\u003econtrol. The system must use the HHS-approved warning banner text unless the system is collecting Federal Tax Information (FTI), then the \u003ca href=\"https://www.irs.gov/pub/irs-pdf/p1075.pdf\"\u003eIRS Publication 1075\u003c/a\u003e requires the system to use the approved text specified in Exhibit 8 Warning Banner Examples from the \u003cem\u003eIRS AC-08 System Use Notification\u003c/em\u003e control standard. The warning banner notification message must be displayed upon successful logon, obtaining an affirmation in the workflow from the user of their understanding and acceptance of the warning before gaining system access. This warning message notifies users that the CMS system is owned by the U.S. Government and describes conditions for access, acceptable use, and access limitations. The warning is presented at the secure gateway, and again at the system/device level. The approved warning/notification message should require forced user interaction and require the user to explicitly select the “I Accept” button before proceeding to log on to the system. The system should retain the notification message or banner on the screen until users take the explicit action(s) to log on to or further access the system.\u003c/p\u003e\u003cp\u003eThe warning banner language has very important legal implications for CMS and its system resources. Should content need to be added to this banner, submit the modified warning banner language to the CMS CIO for review and approval prior to implementation. If a system has character limitations related to the warning banner display, the CMS CIO can provide an abbreviated warning banner version. The \u003ca href=\"https://www.irs.gov/pub/irs-pdf/p1075.pdf\"\u003eIRS Publication 1075\u003c/a\u003e in Exhibit 8 Warning Banner Examples also has approved abbreviated warning banner versions available to use. If this banner is inconsistent with any directives, policies, regulations, or standards, notify the CMS CIO immediately.\u003c/p\u003e\u003cp\u003eAll systems and network devices under CMS control must prominently display the notice and consent banner immediately upon users’ authentication to the system, including, but not limited to, websites, web pages where substantial personal information from the public is collected, Secure File Transfer Protocol (SFTP), Secure Shell (SSH), or other services accessed.\u003c/p\u003e\u003cp\u003eThe \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003eprovides additional requirements for the content and the implementation of System Use Notifications as specified by the AC-08 System Use Notification control standard.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eConcurrent session control\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS defines and implements the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or any combination thereof. A session is defined as an encounter between an end-user interface device (e.g., computer, terminal, process) and an application, including a network logon. One user session is the time between starting the application and quitting or exiting the application. For example, if a user can use separate browsers to open concurrent sessions with the same user account and log out of any of the concurrent sessions to terminate the other sessions, safeguards must be implemented to counteract this type of action.\u003c/p\u003e\u003cp\u003eCMS limits network log-on sessions to one (1) user/network/application session at a time by implementing the appropriate configuration settings. However, if a concurrent session of more than one (1) is required for the system, it needs to be documented in the applicable SSPP and approved by the CMS Authorizing Official (AO) during the Authorized To Operate (ATO) approval process.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDevice lock\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eDevice locks are actions taken to prevent logical access to systems when a period of inactivity has been detected on a CMS user account. This control is configured to protect sensitive information and CUI from unauthorized access when CMS system users are away from their workstations for a CMS-defined period of inactivity. Identification and authentication requirements must be met for users to re-establish access to the system. Group Policy is used to configure the device lock requirements.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing device lock:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS information systems, along with GFE computers distributed to CMS Federal staff and contractors, are configured with a fifteen (15) minute device lock on the operating system. The user will be required to re-authenticate themselves to continue accessing CMS resources.\u003c/li\u003e\u003cli\u003eWindows and UNIX servers are configured to lock the application, after thirty (30) minutes of inactivity. The user will be required to re-authenticate themselves to continue accessing CMS resources.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePattern-hiding displays\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePattern-hiding displays conceal, via the device lock, information with a publicly viewable image. All CMS systems are configured to conceal information that is previously available on the display with a screen saver. Pattern-Hiding Displays mitigate against unauthorized viewing of any sensitive information and CUI, especially PII or PHI. This type of threat is commonly referred to as “shoulder surfing”.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing pattern-hiding displays:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe system conceals information previously available on the display with a screen saver built into the operating system of the GFE.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS users can make use of this display before leaving GFE computers unattended or concealing information from unauthorized personnel.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe login screen is only available by pressing CTRL-ALT-DEL.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eSession termination\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSession termination ensures that all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) continue after the session is terminated. The conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.\u003c/p\u003e\u003cp\u003eCMS systems are configured to terminate user login sessions after a certain period of inactivity. For systems-specific login sessions, the system must implement automatic session termination based on a predefined condition or trigger outlined in their respective system security and privacy plan (SSPP).\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePermitted actions without identification or authentication\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSome specific user actions are permitted on CMS systems without identification or authentication required. Systems may allow a limited number of user actions like access to CMS public websites or other publicly accessible CMS systems that do not contain any sensitive information and CUI, but only the information that is appropriate for public consumption.\u003c/p\u003e\u003cp\u003eAll CMS systems that are not intended to be utilized by the public require proper user account processes and authentication. Please refer to the \u003ca href=\"https://pages.nist.gov/800-63-4/\"\u003eNIST Special Publication (SP) 800-63\u003c/a\u003e series regarding Digital Identity Guidelines (NIST SP 800-63, SP 800-63A, SP 800-63B, SP 800-63C).\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRemote access\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eRemote access is access to CMS systems by users (or processes acting on behalf of users) that communicate through external networks (for example, the Internet or non-secure telecommunication pathways and protocols) via CMS-approved VPNs or CMS VDI via the CITRIX Workspace. The use of CMS-approved VPNs or VDI does not make the access non-remote. However, the use of VPNs or VDI, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) provides sufficient information security assurance to the organization that it can effectively treat such connections as safe internal networks. Remote access to CMS network resources is securely configured and must meet, as a minimum, the following security requirements for posture validation:\u003c/p\u003e\u003col\u003e\u003cli\u003eUp-to-date system patches\u003c/li\u003e\u003cli\u003eCurrent malware/anti-virus software with up-to-date patches\u003c/li\u003e\u003cli\u003eA host-based intrusion detection system(s)\u003c/li\u003e\u003cli\u003eDisable functionality that provides the capability for automatic execution of code and\u003c/li\u003e\u003cli\u003eEmploys CMS-required encryption which is the Federal Information Processing Standard (FIPS) 140-2 validated cryptographic module at a minimum.\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eThe following details the CMS-specific process for implementing the remote access control:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe system should utilize a CMS-approved VPN(s) or VDI to ensure the security of the sessions and the integrity of client-based applications.\u003c/li\u003e\u003cli\u003eCMS users are not allowed to access CMS systems remotely without a CMS-issued RSA hard token or \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-3.pdf\"\u003eFIPS 201\u003c/a\u003e PIV card, along with an approved EUA job code.\u003c/li\u003e\u003cli\u003eAccess to the secure CMS VPN or CMS VDI will authenticate the user account using the EUA job code.\u003c/li\u003e\u003cli\u003eThe VPN solution used by CMS also includes a Network Access Control (NAC) component that performs a security assessment and verifies the latest critical operating system patches and up-to-date malware/anti-virus signatures.\u0026nbsp;\u003c/li\u003e\u003cli\u003eIf the computer fails any one of these checks, it will be quarantined, i.e., preventing remote users from connecting to the CMS network with machines that aren't up to date with malware/anti-virus signatures or OS patch levels, and securing the computer by placing VPN login credentials into a secured area with limited or no access to the CMS network until those conditions are remediated. In the remediation process, CMS users are instructed to obtain required updates from Windows Software Update Service (WSUS) servers or other update servers.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS contractors will be notified that they will need to disconnect from the VPN and update their computers by downloading the latest Microsoft critical patches and/or antivirus signatures before access is granted.\u003c/li\u003e\u003cli\u003eRemote access for privileged functions must be permitted only for compelling operational needs, must be strictly controlled, and must be explicitly authorized, in writing, by the CMS AO, i.e., the CIO (Chief Information Officer) or his/her designated representative.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAdditional information on connecting to the CMS Network using an approved CMS VPN service can be found in the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/RemoteAccessSupport.aspx?PageView=Shared\u0026amp;InitialTabId=Ribbon.WebPartPage\u0026amp;VisibilityContext=WSSWebPartPage#Remote\"\u003eRemote Access Support\u003c/a\u003e. Additional information for CMS Federal Employees or contractors using the CMS VDI can be found at \u003ca href=\"https://vdildap.cms.gov/logon/CMS_VDI_HOW_TO_GUIDE.pdf\"\u003eCMS Employees and Contractors How-To-Guide VDI\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMonitoring and control\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to employ automated mechanisms and establish parameters that facilitate the monitoring and control of remote access. User activities are also monitored and audited to ensure compliance with CMS remote access policies, as applicable to each CMS information system. For more information on remote access, visit the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/RemoteAccessSupport.aspx?PageView=Shared\u0026amp;InitialTabId=Ribbon.WebPartPage\u0026amp;VisibilityContext=WSSWebPartPage#Remote\"\u003eCMS Remote Access Support\u003c/a\u003e website.\u003c/p\u003e\u003cp\u003eAn Intrusion Detection System (IDS) is deployed to protect and monitor the integrity of the systems. Continuous monitoring is also deployed by the CMS Information Security and Privacy Group (ISPG) to ensure compliance with CMS policies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eProtection of confidentiality and integrity using encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems shall implement cryptographic mechanisms to protect remote access sessions. All encryption solutions used throughout CMS must be \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf\"\u003eFIPS 140-3\u003c/a\u003e tested and validated. The confidentiality and integrity of remote sessions, sensitive information and CUI shall be protected with end-to-end encryption commensurate with the sensitivity level of the data.\u003c/p\u003e\u003cp\u003eSystems must utilize a CMS-approved secure VPN or VDI solution to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Every access to the CMS Secure VPN or VDI requires authentication using secure user system account credentials.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWhen applicable and available, sessions should be secured with FIPS 140-3 hardware security modules and FIPS 140-3 compliant algorithms.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManaged Access Control points\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS remote accesses must be routed through authorized and managed network access control points to protect the network connections. A Trusted Internet Connection (TIC) must be utilized for all external network connections.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing managed access control points:\u003c/p\u003e\u003cp\u003eAll systems must utilize CMS-approved secure VPN or VDI connections to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Administrative access should be limited to designated CMS-approved VPN or VDI solutions. Based on the designated VPN or VDI solution, configurations for firewall rules, Intrusion Detection and Prevention System policies, server policies, and active directory group policies as implemented in collaboration with AC control family requirements, will limit remote access.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrivileged commands and access\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe execution of privileged commands and access via remote access is restricted. Remote access for privileged commands and access should only be permitted if operational needs cannot otherwise be met via a direct connection in a secured access-controlled environment.\u003c/p\u003e\u003cp\u003eSystems should be configured to allow privileged user accounts to execute privileged commands to security-relevant information via remote access under special circumstances associated with the need to complete a task for critical operational needs. If a system opts to enable appropriate privileged commands via remote access, the rationale for the permission must be documented in the SSPP and approved via the CMS AO during the ATO approval process.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWireless access\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS monitors for unauthorized wireless access and prohibits the installation of wireless access points (WAP) in its systems. The Infrastructure and User Services Group (IUSG) are in charge of managing wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS information systems and prohibits the installation of WAP to systems unless explicitly authorized, in writing, by the CMS AO, i.e., the CMS CIO or the designated representative.\u003c/p\u003e\u003cp\u003eIf wireless access is authorized and approved by the AO during the ATO process, CMS establishes usage restrictions and configuration/connection requirements such as:\u003c/p\u003e\u003cul\u003e\u003cli\u003eFIPS 140-3 encryption protection is enabled\u003c/li\u003e\u003cli\u003eAccess points are placed in secure areas where physical access controls can be implemented, monitored, and audited\u003c/li\u003e\u003cli\u003eAccess points are shut down, i.e., powered off, when not in use (nights, weekends)\u003c/li\u003e\u003cli\u003eA stateful inspection firewall is implemented between the wireless network and the wired infrastructure; where a direct telecommunication wired connection is established\u003c/li\u003e\u003cli\u003eMedia Address Control (MAC) address authentication is utilized\u003c/li\u003e\u003cli\u003ePersonal firewalls are utilized on the endpoint device, e.g., laptop, and file sharing is disabled on all wireless clients\u003c/li\u003e\u003cli\u003eIntrusion detection agents are deployed on the wireless side of the firewall device\u003c/li\u003e\u003cli\u003eWireless activity is monitored and recorded, and the records are regularly reviewed\u003c/li\u003e\u003cli\u003eAdheres to \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Wireless-Acceptable-Use-Policy.pdf#search=cms%2520rules%2520of%2520behavior\"\u003eCMS Policy for Wireless Client Access\u003c/a\u003e and \u003ca href=\"https://www.hhs.gov/sites/default/files/standard_2009-0003_001s_-_ocio.DOC\"\u003eHHS Standard for IEEE 802.11 Wireless Local Area Network (WLAN)\u003c/a\u003e.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eRogue wireless devices, i.e., unauthorized WAPs, that are connected to the network can be detected by the wireless intrusion prevention system (WIPS). Any unauthorized WAP connected to the CMS internal network will be detected and locked out at the switch level (performing a port lock action on the switch IP address connection point) and then followed up as a potential security incident using the CMS Incident Response Process. For additional information on how to connect an approved wireless connection to CMS, please refer to the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Wireless-Network-Employee-Connection-Guide.pdf\"\u003eCMS Wireless Network Connection Guide\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthentication and encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems are protected against wireless networking capabilities by using authentication and the encryption of both users and devices. Wireless networking capabilities represent a significant potential vulnerability that can be exploited by adversaries.\u003c/p\u003e\u003cp\u003eThe CMS Baltimore Data Center Group (BDCG) manages the wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS systems and prohibits the installation of WAP devices to systems unless explicitly authorized, in writing, by the CMS AO, i.e., the CMS CIO or the designated representative. For more information on Authentication and Encryption, please refer to the System and Communications Protection (SC) and the Identification and Authentication (IA) Controls of the \u003cem\u003eCMS ARS\u003c/em\u003e.\u003c/p\u003e\u003cp\u003eAll wireless access points are configured to authenticate users and devices before access is granted. Also, all WLAN components use FIPS 140-3 approved cryptographic algorithms to protect the confidentiality and integrity of WLAN communications.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable wireless networking\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll wireless network capabilities embedded within CMS systems components must be disabled before issuance and deployment. Disabling all the wireless capabilities when not needed for essential CMS missions or functions can reduce susceptibility to threats by adversaries involving wireless technologies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRestrict configurations by users\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccess enforcement mechanisms are employed to restrict access to configure wireless networking capability only to selected and authorized users. Only CMS-approved and authorized users should be allowed to configure network capabilities. The responsibility of securing the CMS wireless network should rest in the hands of network administrators with system administrator (SYSADMIN) type accounts, that only allow SYSADMIN type commands to be performed under this type of SYSADMIN role.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing restrictions on access to wireless configurations.\u003c/p\u003e\u003col\u003e\u003cli\u003eCMS restricts access to wireless networking configurations only to the authorized role of a network administrator.\u003c/li\u003e\u003cli\u003eWireless networking capabilities are also confined within CMS boundaries.\u003c/li\u003e\u003c/ol\u003e\u003ch2\u003e\u003cstrong\u003eAntennas and transmission power levels\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS limits the unauthorized use of wireless communications outside of CMS-controlled boundaries. Radio antennas and transmission power levels must be calibrated to reduce the probability that usable signals can be intercepted by unauthorized users. Network traffic must be continuously monitored within CMS boundaries to detect and respond to intrusion and network misuse.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccess Control for mobile devices\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAll CMS-controlled mobile devices, including when such devices are outside of the CMS-controlled areas, must abide by the established configuration requirements, connection requirements, and implementation guidance in the CMS ARS when connected to the CMS environment.\u003c/p\u003e\u003cp\u003eCMS network administrators must set usage restrictions, configuration, and connection requirements for all mobile devices. The \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Mobile-Device-Guidance.pdf#search=CMS%2520Guidance%2520for%2520Government%2520Furnished%2520Mobile%2520Devices\"\u003eCMS Guidance for Government Furnished Mobile Devices\u003c/a\u003e provides information on the responsible use of CMS-issued mobile devices.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing access control requirements for mobile devices:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAll CMS-issued laptops utilize full disk encryption software that is FIPS 140-3 validated\u003c/li\u003e\u003cli\u003eCMS-procured removable storage media are configured for use by the contracted maintainer and use CMS-approved encryption for the storage of information\u003c/li\u003e\u003cli\u003eAny non-GFE equipment being connected internally to the network requires a fully signed \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eRules of Behavior for General Users\u003c/a\u003e form which details CMS' Operational Division (OpDiv) security responsibilities relative to the equipment being connected, along with prior approval from the CMS AO during the ATO process. The document also details the responsibilities the requester will fulfill or face possible disciplinary and/or non-disciplinary actions. Please refer to the HHS RoB, Section 6.3 Non-compliance for a list of potential adverse actions that may be taken against a user for non-compliance.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eGFE equipment may be connected remotely via VPN (using the established VPN for the Contractors' process). VPN authentication involves remote NAC checks that ensure the integrity of the system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFull device or container-based encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS-issued mobile devices must be encrypted using full device or container-based encryption mechanisms to protect the confidentiality and integrity of the data and information contained. Container-based encryption provides a more fine-grained approach to data and information encryption on mobile devices, including encrypting selected data structures such as files, records, or fields. Since mobile devices are more likely to be lost or stolen, sensitive information on a mobile device(s) is more vulnerable to unauthorized disclosures and encryption reduces this vulnerability.\u003c/p\u003e\u003cp\u003eAt CMS, FIPS 140-3 encryption mechanisms are used to protect the confidentiality and integrity of information on CMS-issued mobile devices. CMS utilizes media and port protection software to encrypt removable media endpoint devices.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eUse of external systems\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS employs mechanisms that prohibit the use of external devices to access the systems within the network without a formal approval process. CMS complies with the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e, which strictly prohibits the use of personal devices to conduct CMS-related business without written and approved authorization by the CMS AO under the ATO approval process.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for the use of external information systems control requirements:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS prohibits the use of external systems without explicit written approval from the AO.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS does not allow the use of external systems that are not approved and do not meet CMS security requirements. If approval is granted, the recipient verifies the terms and conditions, ensures the required controls are implemented for the identified FIPS 199 system categorization to mitigate the associated risks, limits user access accordingly, and documents the control implementations in the SSPP.\u003c/li\u003e\u003cli\u003eAccess to PII from external systems (including, but not limited to, personally owned information systems/devices) is reinforced by a binding agreement to terms and conditions of the CMS’s privacy requirements to ensure awareness and accountability of both parties under the Interconnection Security Agreement approval process.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eLimits on authorized use\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS ensures that only authorized users are permitted to use external systems to access its systems, and these systems must have the necessary security configurations implemented before access is granted. These necessary security requirements are implemented and the CMS access control policies regarding the use of external systems are enforced.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for limiting the authorized use of external information systems:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS does not permit the use of external systems that are not approved and do not meet the CMS security requirements for accessing CMS systems per the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eExternal systems can only access CMS systems using approved VPN or VDI access and firewall/security verification software, which must be installed on each machine. This applies to federal employees and contractor personnel utilizing CMS GFE (laptop or desktop) only or approved corporate-issued computers per the contract.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePortable storage devices — restricted use\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS limits the use of its controlled-portable storage devices in external systems. Conditions of use or restrictions on these devices should be documented and configured by network administrators.\u003c/p\u003e\u003cp\u003eCMS has configured CMS-issued portable and mobile devices to meet federal requirements. CMS has provided several control implementations that support and manage how its information is used within portable storage devices. These include a policy to incorporate a methodology for protecting the information and the rules used to manage the information while in transit. For more information, review the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/StorageDeviceandEncryption.aspx\"\u003eCMS Storage Device and Encryption\u003c/a\u003e website.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eInformation sharing\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eInformation sharing control puts restrictions on CMS-sensitive information and CUI, such as personally identifiable information (PII), contract-sensitive information, proprietary information, and classified information related to special access programs or compartments, based on a formal or administrative risk-based determination. Depending on the information-sharing circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program/compartment.\u003c/p\u003e\u003cp\u003eGuidance for information sharing between CMS and other organizations is specified in the CMS Privacy Handbook. The document specifies the requirements for information sharing in the following documents:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-interconnection-security-agreement-isa\"\u003eInterconnection Security Agreement (ISA):\u003c/a\u003e System interconnections are defined within CFACTS and require a supporting “signed” ISA between CMS and non-CMS organizations as part of the SSP/ATO process.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-memorandum-understanding-mou\"\u003eMemorandum of Understanding (MOU):\u003c/a\u003e Defines the relationship of two or more federal partners that enter into a joint project or collaboration in which they each contribute their resources.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-data-use-agreement-dua\"\u003eData Use Agreement (DUA):\u003c/a\u003e 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.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-information-exchange-agreement-iea\"\u003eInformation Exchange Agreements (IEA):\u003c/a\u003e Is needed when Personally Identifiable Information (PII) needs to be shared externally, and that will not have an adverse impact on the beneficiary.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-computer-matching-agreement-cma\"\u003eComputer Matching Agreements (CMA):\u003c/a\u003e A written agreement establishing the conditions, safeguards, and procedures under which a federal agency agrees to disclose data with another federal or state agency when there is a computerized comparison of two or more automated Systems of Records (SORs).\u003c/li\u003e\u003cli\u003eOther forms of documented agreements required for different situations.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor additional guidance related to the above agreements and documents, please review the Privacy Handbook. The ISSO is responsible for developing and managing any agreement utilized for information sharing and should coordinate with the appropriate Data Guardian and Privacy Advisor.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePublicly accessible content\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePer applicable laws, executive orders, directives, policies, regulations, standards, and guidelines, the general public is not authorized to access non-public information, such as information protected under the Privacy Act information (e.g., PII/PHI), CMS sensitive information (e.g., data with a federal information classification standard, For Official Use Only [FOUO], or Controlled Unclassified Information [CUI]), and CMS proprietary information (e.g., proprietary acquisition data). This control addresses systems that are controlled by CMS and are accessible to the public, typically without requiring identification or authentication.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for adhering to requirements for publicly accessible content:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNetwork Connections\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eCMS Website Owners/Administrators are charged with limiting the connections to publicly available CMS websites and web services to approved secure protocols and adhering to Hypertext Transfer Protocol (HTTP) Strict Transport Security (HSTS) practices.\u003c/p\u003e\u003cul\u003e\u003cli\u003eAlthough general public access to the CMS internal network is not allowed, CMS websites are accessible by the public and protected by several Private Internet Exchange (PIX) firewalls\u003c/li\u003e\u003cli\u003eOutbound internet connections from CMS users are protected by Application Intelligence (NG AI) firewalls.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003ePublic Content\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CMS system personnel should reach out to the CMS Information Security and Privacy Group (ISPG) to review the proposed content of information on a publicly accessible system (including a public website) before posting or publication to ensure that nonpublic information is not included.\u003c/li\u003e\u003cli\u003eThe frequency of the review will be commensurate with the frequency information is posted. Whenever new information is being considered to be uploaded to a site, it should trigger a review process to ascertain it complies with CMS policy.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe system should consult the ISPG for clarification as to if the information is suitable for public accessibility and publication.\u003c/p\u003e"])</script><script>self.__next_f.push([1,"1e:T5673,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is the purpose of a Privacy Impact Assessment (PIA)?\u0026nbsp;\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Privacy Impact Assessment (PIA) is an analysis of how personally identifiable information (PII) is collected, used, shared, and maintained. The purpose of a PIA is to demonstrate that system owners have consciously incorporated privacy protections within their systems for information supplied for by the public.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePIAs are required by the E-Government Act of 2002, which was enacted by Congress in order to improve the management of Federal electronic government services and processes. Section 208 of the E-Government Act specifically requires PIAs to be created when a federal agency develops or procures new information technology that involves the collection, maintenance, or dissemination of information in identifiable form.\u003c/p\u003e\u003cp\u003eFurther, because the E-Government Act also includes a provision requiring PIAs to be published publicly on agency websites, they allow CMS to communicate more clearly with the public about how we handle information, including how we address privacy concerns and safeguard information. Copies of completed PIAs are\u003ca href=\"https://www.hhs.gov/pia/index.html\"\u003e posted on the HHS website\u003c/a\u003e upon completion to offer transparency to the public.\u003c/p\u003e\u003cp\u003ePIAs must be completed in the following situations:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eFor all new systems that collect PII from 10 or more members of the general public, a PIA is required to be completed as part of the broader Authority to Operate (ATO) process.\u003c/li\u003e\u003cli\u003eFor every existing system that collects PII from 10 or more members of the general public, a PIA must be reviewed and re-approved once every three years. System/Business Owners and Information System Security Officers (ISSOs) must review and revise as necessary, and submit PIAs for re-approval no later than three years from the last HHS approval date.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor any existing system undergoing a \u003cstrong\u003emajor change\u003c/strong\u003e, an updated PIA is required.\u003c/li\u003e\u003cli\u003eAn existing system that is going through the ATO process may need to update their PIA paperwork if it’s close to expiring; an ATO cannot be completed with an expired or incomplete PIA.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIf your FISMA system does not meet the requirements above, it may not require a traditional PIA. In these instances, there may be other Privacy compliance requirements for your system or application. For example, you may be required to complete a different type of assessment (such as a Privacy Threshold Analysis (PTA), Third Party Website Application (TPWA) Privacy Impact Assessment, or Internal Privacy Impact Assessment).\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePIA roles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003ch3\u003e\u003cstrong\u003eHHS Chief Information Officer (CIO)/Senior Agency Official for Privacy (SAOP)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAt HHS, the Chief Information Officer (CIO) is designated as the Senior Agency Official for Privacy (SAOP) and provides the overall program structure for the completion of PIAs across all operating divisions. Responsibilities for the SAOP include, but are not limited to the following:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDevelop a standard form for HHS PIAs\u003c/li\u003e\u003cli\u003eReview PIAs from all operating divisions for adequacy, consistency, and compliance with federal and HHS requirements\u003c/li\u003e\u003cli\u003eIf the PIA meets HHS’s requirements, the PIA is signed by the SAOP, which finalizes the PIA for a period depending on the type of PIA\u003c/li\u003e\u003cli\u003eEnsure all PIAs are published and made publicly available on HHS.gov\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Senior Official for Privacy (SOP)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAt CMS, the Senior Official for Privacy (SOP) is the lead privacy official responsible for administering the agency PIA process and providing direction for the CMS privacy program. Unresolved privacy risks and other potential issues should be addressed before submission to the CMS SOP for final review. Responsibilities of the CMS SOP include, but are not limited to the following:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eEstablish a CMS specific framework for the development and completion of PIAs in accordance with federal and HHS requirements\u003c/li\u003e\u003cli\u003eReview and approve all PIAs for completion and consistency prior to submission to the HHS SAOP in coordination with the CMS Final Approver\u003c/li\u003e\u003cli\u003eSigning the PIA on behalf of CMS once the PIA satisfies federal and HHS requirements (The PIA will still require HHS’s final signature before publication to the HHS website)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS System Owner/Business Owner\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eInformation System Owners or Business Owners are individuals who are responsible for CMS FISMA systems or electronic information collections. System/Business Owners:\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview, revise, and submit PIAs for approval for new systems or re-approval whenever a change to an IT system, a change in CMS practice, or another factor alters the privacy risks associated with the use of the IT system or electronic information collection.\u0026nbsp;\u003c/li\u003e\u003cli\u003eAllocate proper resources to permit identification and remediation of privacy risks and weaknesses identified on PIAs.\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview, revise, and submit PIAs for re-approval three years from the last approval date, and as part of the authorization process as required.\u0026nbsp;\u003c/li\u003e\u003cli\u003eComply with all relevant Privacy Act requirements regarding any system of records, including, but not limited to, providing individuals with procedures for access and amendment of records.\u003c/li\u003e\u003cli\u003eEnsure all artifacts are in place as needed such as a Computer Matching Agreement (CMA), Information Exchange Agreements (IEA), or any other agreement when sharing information.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDepending on the structure of your specific team, some System/Business Owner responsibilities will be completed by the trained ISSO. Alternatively, some teams may utilize their System/Business Owner to complete ISSO tasks. Your team will decide what structure works best for your unique needs.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCMS Privacy Advisor\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Privacy Advisor has in-depth knowledge of privacy risks and can help your team meet the requirements for your PIA. The Privacy Advisor will complete the following tasks:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview component PIAs for accuracy, consistency and compliance; coordinating with the Cyber Risk Advisor (CRA) to identify any outstanding privacy risks prior to submission to the CMS SOP.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEnsure answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCheck each PIA for other Privacy-related requirements (e.g. Privacy Act implications).\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview and edit each PIA for grammatical mistakes or incomplete responses.\u0026nbsp;\u003c/li\u003e\u003cli\u003eProvide input and guidance as needed regarding any other privacy weaknesses as identified.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Cyber Risk Advisor (CRA)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CRA is responsible for coordinating the drafting and review process of the PIA with the CMS office or center in which they are representing. The CRA will:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eCommunicate with System/Business Owners through the authorization process, and ensure that the PIA is included in the authorization package.\u003c/li\u003e\u003cli\u003eReview PIAs submitted by the ISSO or System Owner for potential security and privacy risk, this can include:\u003cul\u003e\u003cli\u003eChecking that information in the PIA matches other artifacts in the ATO package as needed, including checking for grammatical mistakes or incomplete responses.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEnsuring the answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eCoordinate with the Privacy Advisor to identify any potential privacy risks during the review of the PIA.\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview PIAs sent back from the SOP and/or HHS and coordinate with the ISSO and Privacy Advisor to resolve the outstanding comments as needed.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCoordinate with the Privacy Advisor to submit completed PIAs for approval to the CMS SOP.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Information System Security Officer (ISSO)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO provides oversight and develops documentation to ensure the completion of the Security Assessment and Authorization (SA\u0026amp;A) process for their information systems. The ISSO typically performs this function on behalf of the System/Business Owner for the FISMA system. The PIA is included as one of the artifacts in the Security Assessment and Authorization package. The ISSO will:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDraft a new PIA or modify a PIA in coordination with the System Owner and CRA to address major changes or PIA requirements.\u003c/li\u003e\u003cli\u003eContact the CRA to obtain either HHS or CMS PIA guidance when required.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEngage with the System/Business Owner, CRA, Privacy Advisor, and CMS leadership to ensure all comments and suggestions are included in the PIA\u003c/li\u003e\u003cli\u003eAssist in identifying and remediating potential privacy risks and notify System/Business Owners of PIA requirements;\u0026nbsp;\u0026nbsp;\u003c/li\u003e\u003cli\u003eInform the CRA when a planned, new or existing system will require a PIA\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eSteps for completing your PIA\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe Department of Health and Human Services (HHS) issues the master guidance for completing PIAs. ISPG has taken the guidance provided by HHS and translated it into a questionnaire found on\u003ca href=\"https://cfacts.cms.gov/apps/ArcherApp/Home.aspx\"\u003e CFACTS\u003c/a\u003e. ISSOs can log in to CFACTS to complete the questionnaire with guidance from the System/Business Owner and the assigned Cyber Risk Advisor (CRA). A step-by-step guide to answering the questions required to complete the PIA can be found within the PIA \u0026amp; PTA Writer’s Handbook, which is written by HHS and can be found as a resource on the front page of each question in CFACTS. If you would like a copy of the PIA \u0026amp; PTA Writers Handbook, please contact the Privacy Office. The procedures below give a summary review of the actions necessary to complete a new PIA or modify an existing PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 1: PIA initial draft\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: SO/BO, ISSO, Cyber Risk Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eFollowing any of the scenarios or major changes that would require the completion of a PIA, the System/Business Owner works with the ISSO to draft a new or revised PIA in CFACTS. Upon completion of the new or revised PIA, the System/Business Owner or ISSO will contact the CRA for review. In CFACTS, the queue for the System/Business owner or ISSO is “ISSO Submitter” for the PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 2: PIA review / revision\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: CRA, Privacy Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe CRA reviews the PIA in collaboration with the Privacy Advisor and coordinates recommended changes with the system/business owner or ISSO. Any identified privacy risks or compliance issues should be resolved before submission to the SOP for approval. If the SOP or SAOP recommends changes, the review process will return to this step as needed until the PIA is approved and finalized by the Senior Agency Official for Privacy (SAOP).\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 3: PIA approval\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: CMS Senior Official for Privacy (SOP), Final Approver\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SOP or designated Final Approver will review the PIA and recommend approval to HHS if no changes are recommended.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 4: PIA signing\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: Senior Agency Official for Privacy (SAOP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SAOP will designate staff to review all PIAs before approval for signature. If no changes are recommended, the SOP and SAOP will digitally sign the PIA. Once signed by the SOP and SAOP, the PIA is approved and complete for a length of time as discussed above.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 5: PIA posting\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: Senior Agency Official for Privacy (SAOP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SAOP will send the completed PIA to HHS\u003cstrong\u003e. \u003c/strong\u003eHHS will submit the final PIA for publication to the HHS PIA internet site at\u003ca href=\"https://www.hhs.gov/pia\"\u003e https://www.hhs.gov/pia\u003c/a\u003e.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eTips for completing your PIA\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBefore starting to fill out your PIA, obtain and review any available program and system documentation. This may include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eWebsites that explain the service or business process supported by the system;\u003c/li\u003e\u003cli\u003eInformation Collection Requests (ICRs) if the system collects information from the public and is subject to the Paperwork Reduction Act (PRA); if unsure, please reach out to the PRA office.\u0026nbsp;\u003c/li\u003e\u003cli\u003ePrivacy Act Statements (PASs) and System of Records Notices (SORNs) if records in the system are subject to the Privacy Act;\u003c/li\u003e\u003cli\u003eAgency IT Portfolio Summaries (formerly called Exhibit 53s) or any Major IT Investment Business Cases (formerly called Exhibit 300s);\u003c/li\u003e\u003cli\u003eEnterprise Program Lifecycle Artifacts such as a System Security and Privacy Plan (SSPP); and\u003c/li\u003e\u003cli\u003eAny handbooks or other guidance on how to use the system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIt may be possible to reuse language from these documents to respond to questions. However, make sure you review all copied text to verify that it is specific to the system being reviewed, is complete, and makes sense absent the rest of the document. Text copied from marketing materials and system planning documents may discuss functions that were never purchased or implemented. Text copied from a SORN or budget document may describe more than one system.\u003c/p\u003e\u003cp\u003eThe purpose of a PIA is to provide the general public with information about how CMS systems collect and share user data. The general public is the audience for PIAs, so it’s essential to keep your end users in mind when drafting your PIA.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eAnswer each question briefly; text fields have a limited capacity when translated to the final documentation in CFACTS\u003c/li\u003e\u003cli\u003eWrite in a way that is easily understood by the general public; avoid using overly technical language, and clearly define technical terms and references if needed to describe a system.\u003c/li\u003e\u003cli\u003eDefine each acronym the first time it is used; use the acronym alone in all subsequent references.\u003c/li\u003e\u003cli\u003eDo not include sensitive or confidential system information or information that could allow a potential threat source to gain unauthorized access into the system (e.g., do not provide detailed information on technical security controls)\u003c/li\u003e\u003cli\u003eProvide information about authentication credentials. Reviewers need to know if the system is accessed using system-specific login information such as a username and password or if the system uses only PIV access and single sign-on authentication. The login method determines how user credentials are stored outside the system boundary. Please include a statement indicating whether login information is stored in the system.\u003c/li\u003e\u003cli\u003eMake it clear who the “users” are for your system. In some cases, it may be confusing whether “users” refers to individuals creating records about themselves or whether “users” are CMS staff members receiving and acting on this information. Please make this distinction clear the first time the term “users” is used. If contractors are listed as users, please cite if contractors are “direct” or “indirect”.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eGuidance for specific PIA questions\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCompleting a Privacy Impact Assessment (PIA) can be a challenge. It’s essential to provide all the relevant information while ensuring it is correct and up to date. The following guidance comes from the Privacy Office, as well as a number of ISSOs and System/Business Owners who have experience completing successful PIAs in CFACTS.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eFor PIA question 6b, make sure the ISSO information is correct and up to date.\u003c/li\u003e\u003cli\u003eWhen answering question 10, consider all changes that have occurred since the PIA was last finalized, as well as the changes that will occur when the PIA is finalized. All changes, whether or not they pose a new privacy risk, should be documented. Examples of changes include changing the physical location of a server or adding additional collection of new PII elements.\u003c/li\u003e\u003cli\u003eFor PIA question 11, you should include what HHS functions are supported by the system and how the system completes those functions. Your response should be concise and specific, and should not contain jargon or overly technical terms so that a reader with no prior knowledge of the system will understand the response. Don’t forget to spell out all acronyms on first usage.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor PIA question 12, list and describe all types of information collected by the system regardless of whether that information is considered PII. Make sure to include how long information is stored in the system. If the system holds system-specific access credentials, e.g., username, password, please describe those components in the response to this question. Specify whether the username and/or password are created by the individual, generated by the system, provided by a system administrator, or established through some other process.\u0026nbsp; Reminder: Any types of PII listed in this response also need to be listed in PIA question 15.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor PIA question 12, describe why the information listed in the question is collected. The response to this question should consider all information, whether or not it is PII. The response to this question should also specify what information is collected about each category of individual and should document and discuss if records are retrieved by PII elements.\u003c/li\u003e\u003cli\u003eFor PIA question13, include a brief description of the method of record retrieval, if you answered “Yes'' to PIA question 22 regarding System of Record Notification (SORN). Note the PII used and categories of individuals to whom the PII relates.\u0026nbsp;\u003cul\u003e\u003cli\u003eAn example is: The Physical Security System (PSS) regularly uses PII to retrieve system records including using the last name, employee ID number, and/or work phone number of CMS employees, contractors, and members of the public authorized to access the main campus and satellite offices.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003ePIA question 14 is calculated by the system. Reminder: If the response to this question is No, PIA questions 15 through 38 should no longer appear on the form.\u0026nbsp;\u003c/li\u003e\u003cli\u003eIf PIA question 15 is shown, check all the boxes that apply. If the information collected by the system is not described by any of the items in the list, there is a text field under ‘Other’ where you can list additional information. Your response should include all types of PII regardless of type sensitivity, or whether it is from employees or the public. Reminder: PII elements need to be accounted for in both PIA question 12 and PIA question 15.\u003c/li\u003e\u003cli\u003ePIA question 20 should describe all the ways Social Security Numbers (SSNS) are used in the system (if applicable). You’ll need to share when, where, and why an SSN is disclosed or shared; and why the SSN is used rather than another identifier.\u0026nbsp;\u003cul\u003e\u003cli\u003eNOTE: Employer Identification Number (EIN) also known as Federal Employer Identification Number (FEIN) or Tax Identification Number (TIN) or Federal Tax Identification Number (FTIN).\u0026nbsp; Individuals may choose to use their SSN as their EIN or FTIN. Typically, this would be sole proprietors or other small business owners who use SSN as EIN for tax purposes. EIN often appears in the format XX-XXXXXXX and may not stand out as a SSN. Any time that Social Security Numbers are involved, examine whether the collection and/or use of the SSN can be eliminated.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003eReminder: If the response to this question states that SSNs are collected, SSNs should also be listed in the response to PIA question 15.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePIA question 21 asks for the legal authorities governing information collection. Every system with PII must have an authority to collect this information. This will be a statute or Executive Order that either (a) permits or requires collection of the PII, or (b) permits or requires the underlying activity, for which it is necessary to collect PII.\u003c/li\u003e\u003cli\u003ePIA questions 22 and 22a are relevant to System of Record Notifications (SORNs). If the\u003c/li\u003e\u003cli\u003esystem uses PII to retrieve records, it may need to be covered by a SORN. Any system that has already received Privacy Office signatures should already reference a SORN. If not, you may need to seek guidance from ISPG or DSPPG to determine whether a SORN is required and in identifying an existing SORN that might apply. Please also review your response to PIA question 13 to ensure that it matches with your response here in question 22.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEach system has unique functions and answers to questions will be different for different systems. Question 23 determines whether your system needs an Information Collection Approval number from the White House Office of Management and Budget (OMB). In some cases, when you answer question 23, question 23a will appear. It asks about an OMB Information Collection Approval number. Under the Paperwork Reduction Act (PRA), the System/Business Owner or ISSO may need to obtain an information collection approval number from the OMB. Use the information in the CMS guidance and HHS PIA Writers’ Handbook regarding this question to contact subject matter experts as needed.\u003c/li\u003e\u003cli\u003eFor PIA question 27, please state that any system that utilizes information obtained from the Enterprise Portal (EIDM) must provide individuals the option to opt-out of information sharing. And similar to PIA question 25, if EIDM has its own PIA for CMS please add this statement.\u003c/li\u003e\u003cli\u003eFor PIA question 29, Identify System Acronym\u003c/li\u003e\u003cli\u003eFor PIA question 37, NARA Disposition Schedule ID, and the retention period described by the schedule, should be included\u003c/li\u003e\u003cli\u003ePIA question 37 asks about the system retention schedule. Every system (whether it contains PII or not) should have been made subject to an information retention schedule. Check with the Records Officer to identify the appropriate retention schedule.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"1f:T5673,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is the purpose of a Privacy Impact Assessment (PIA)?\u0026nbsp;\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Privacy Impact Assessment (PIA) is an analysis of how personally identifiable information (PII) is collected, used, shared, and maintained. The purpose of a PIA is to demonstrate that system owners have consciously incorporated privacy protections within their systems for information supplied for by the public.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePIAs are required by the E-Government Act of 2002, which was enacted by Congress in order to improve the management of Federal electronic government services and processes. Section 208 of the E-Government Act specifically requires PIAs to be created when a federal agency develops or procures new information technology that involves the collection, maintenance, or dissemination of information in identifiable form.\u003c/p\u003e\u003cp\u003eFurther, because the E-Government Act also includes a provision requiring PIAs to be published publicly on agency websites, they allow CMS to communicate more clearly with the public about how we handle information, including how we address privacy concerns and safeguard information. Copies of completed PIAs are\u003ca href=\"https://www.hhs.gov/pia/index.html\"\u003e posted on the HHS website\u003c/a\u003e upon completion to offer transparency to the public.\u003c/p\u003e\u003cp\u003ePIAs must be completed in the following situations:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eFor all new systems that collect PII from 10 or more members of the general public, a PIA is required to be completed as part of the broader Authority to Operate (ATO) process.\u003c/li\u003e\u003cli\u003eFor every existing system that collects PII from 10 or more members of the general public, a PIA must be reviewed and re-approved once every three years. System/Business Owners and Information System Security Officers (ISSOs) must review and revise as necessary, and submit PIAs for re-approval no later than three years from the last HHS approval date.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor any existing system undergoing a \u003cstrong\u003emajor change\u003c/strong\u003e, an updated PIA is required.\u003c/li\u003e\u003cli\u003eAn existing system that is going through the ATO process may need to update their PIA paperwork if it’s close to expiring; an ATO cannot be completed with an expired or incomplete PIA.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIf your FISMA system does not meet the requirements above, it may not require a traditional PIA. In these instances, there may be other Privacy compliance requirements for your system or application. For example, you may be required to complete a different type of assessment (such as a Privacy Threshold Analysis (PTA), Third Party Website Application (TPWA) Privacy Impact Assessment, or Internal Privacy Impact Assessment).\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePIA roles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003ch3\u003e\u003cstrong\u003eHHS Chief Information Officer (CIO)/Senior Agency Official for Privacy (SAOP)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAt HHS, the Chief Information Officer (CIO) is designated as the Senior Agency Official for Privacy (SAOP) and provides the overall program structure for the completion of PIAs across all operating divisions. Responsibilities for the SAOP include, but are not limited to the following:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDevelop a standard form for HHS PIAs\u003c/li\u003e\u003cli\u003eReview PIAs from all operating divisions for adequacy, consistency, and compliance with federal and HHS requirements\u003c/li\u003e\u003cli\u003eIf the PIA meets HHS’s requirements, the PIA is signed by the SAOP, which finalizes the PIA for a period depending on the type of PIA\u003c/li\u003e\u003cli\u003eEnsure all PIAs are published and made publicly available on HHS.gov\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Senior Official for Privacy (SOP)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAt CMS, the Senior Official for Privacy (SOP) is the lead privacy official responsible for administering the agency PIA process and providing direction for the CMS privacy program. Unresolved privacy risks and other potential issues should be addressed before submission to the CMS SOP for final review. Responsibilities of the CMS SOP include, but are not limited to the following:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eEstablish a CMS specific framework for the development and completion of PIAs in accordance with federal and HHS requirements\u003c/li\u003e\u003cli\u003eReview and approve all PIAs for completion and consistency prior to submission to the HHS SAOP in coordination with the CMS Final Approver\u003c/li\u003e\u003cli\u003eSigning the PIA on behalf of CMS once the PIA satisfies federal and HHS requirements (The PIA will still require HHS’s final signature before publication to the HHS website)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS System Owner/Business Owner\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eInformation System Owners or Business Owners are individuals who are responsible for CMS FISMA systems or electronic information collections. System/Business Owners:\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview, revise, and submit PIAs for approval for new systems or re-approval whenever a change to an IT system, a change in CMS practice, or another factor alters the privacy risks associated with the use of the IT system or electronic information collection.\u0026nbsp;\u003c/li\u003e\u003cli\u003eAllocate proper resources to permit identification and remediation of privacy risks and weaknesses identified on PIAs.\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview, revise, and submit PIAs for re-approval three years from the last approval date, and as part of the authorization process as required.\u0026nbsp;\u003c/li\u003e\u003cli\u003eComply with all relevant Privacy Act requirements regarding any system of records, including, but not limited to, providing individuals with procedures for access and amendment of records.\u003c/li\u003e\u003cli\u003eEnsure all artifacts are in place as needed such as a Computer Matching Agreement (CMA), Information Exchange Agreements (IEA), or any other agreement when sharing information.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDepending on the structure of your specific team, some System/Business Owner responsibilities will be completed by the trained ISSO. Alternatively, some teams may utilize their System/Business Owner to complete ISSO tasks. Your team will decide what structure works best for your unique needs.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCMS Privacy Advisor\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Privacy Advisor has in-depth knowledge of privacy risks and can help your team meet the requirements for your PIA. The Privacy Advisor will complete the following tasks:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview component PIAs for accuracy, consistency and compliance; coordinating with the Cyber Risk Advisor (CRA) to identify any outstanding privacy risks prior to submission to the CMS SOP.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEnsure answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCheck each PIA for other Privacy-related requirements (e.g. Privacy Act implications).\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview and edit each PIA for grammatical mistakes or incomplete responses.\u0026nbsp;\u003c/li\u003e\u003cli\u003eProvide input and guidance as needed regarding any other privacy weaknesses as identified.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Cyber Risk Advisor (CRA)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CRA is responsible for coordinating the drafting and review process of the PIA with the CMS office or center in which they are representing. The CRA will:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eCommunicate with System/Business Owners through the authorization process, and ensure that the PIA is included in the authorization package.\u003c/li\u003e\u003cli\u003eReview PIAs submitted by the ISSO or System Owner for potential security and privacy risk, this can include:\u003cul\u003e\u003cli\u003eChecking that information in the PIA matches other artifacts in the ATO package as needed, including checking for grammatical mistakes or incomplete responses.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEnsuring the answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eCoordinate with the Privacy Advisor to identify any potential privacy risks during the review of the PIA.\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview PIAs sent back from the SOP and/or HHS and coordinate with the ISSO and Privacy Advisor to resolve the outstanding comments as needed.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCoordinate with the Privacy Advisor to submit completed PIAs for approval to the CMS SOP.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Information System Security Officer (ISSO)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO provides oversight and develops documentation to ensure the completion of the Security Assessment and Authorization (SA\u0026amp;A) process for their information systems. The ISSO typically performs this function on behalf of the System/Business Owner for the FISMA system. The PIA is included as one of the artifacts in the Security Assessment and Authorization package. The ISSO will:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDraft a new PIA or modify a PIA in coordination with the System Owner and CRA to address major changes or PIA requirements.\u003c/li\u003e\u003cli\u003eContact the CRA to obtain either HHS or CMS PIA guidance when required.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEngage with the System/Business Owner, CRA, Privacy Advisor, and CMS leadership to ensure all comments and suggestions are included in the PIA\u003c/li\u003e\u003cli\u003eAssist in identifying and remediating potential privacy risks and notify System/Business Owners of PIA requirements;\u0026nbsp;\u0026nbsp;\u003c/li\u003e\u003cli\u003eInform the CRA when a planned, new or existing system will require a PIA\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eSteps for completing your PIA\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe Department of Health and Human Services (HHS) issues the master guidance for completing PIAs. ISPG has taken the guidance provided by HHS and translated it into a questionnaire found on\u003ca href=\"https://cfacts.cms.gov/apps/ArcherApp/Home.aspx\"\u003e CFACTS\u003c/a\u003e. ISSOs can log in to CFACTS to complete the questionnaire with guidance from the System/Business Owner and the assigned Cyber Risk Advisor (CRA). A step-by-step guide to answering the questions required to complete the PIA can be found within the PIA \u0026amp; PTA Writer’s Handbook, which is written by HHS and can be found as a resource on the front page of each question in CFACTS. If you would like a copy of the PIA \u0026amp; PTA Writers Handbook, please contact the Privacy Office. The procedures below give a summary review of the actions necessary to complete a new PIA or modify an existing PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 1: PIA initial draft\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: SO/BO, ISSO, Cyber Risk Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eFollowing any of the scenarios or major changes that would require the completion of a PIA, the System/Business Owner works with the ISSO to draft a new or revised PIA in CFACTS. Upon completion of the new or revised PIA, the System/Business Owner or ISSO will contact the CRA for review. In CFACTS, the queue for the System/Business owner or ISSO is “ISSO Submitter” for the PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 2: PIA review / revision\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: CRA, Privacy Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe CRA reviews the PIA in collaboration with the Privacy Advisor and coordinates recommended changes with the system/business owner or ISSO. Any identified privacy risks or compliance issues should be resolved before submission to the SOP for approval. If the SOP or SAOP recommends changes, the review process will return to this step as needed until the PIA is approved and finalized by the Senior Agency Official for Privacy (SAOP).\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 3: PIA approval\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: CMS Senior Official for Privacy (SOP), Final Approver\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SOP or designated Final Approver will review the PIA and recommend approval to HHS if no changes are recommended.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 4: PIA signing\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: Senior Agency Official for Privacy (SAOP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SAOP will designate staff to review all PIAs before approval for signature. If no changes are recommended, the SOP and SAOP will digitally sign the PIA. Once signed by the SOP and SAOP, the PIA is approved and complete for a length of time as discussed above.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 5: PIA posting\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: Senior Agency Official for Privacy (SAOP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SAOP will send the completed PIA to HHS\u003cstrong\u003e. \u003c/strong\u003eHHS will submit the final PIA for publication to the HHS PIA internet site at\u003ca href=\"https://www.hhs.gov/pia\"\u003e https://www.hhs.gov/pia\u003c/a\u003e.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eTips for completing your PIA\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBefore starting to fill out your PIA, obtain and review any available program and system documentation. This may include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eWebsites that explain the service or business process supported by the system;\u003c/li\u003e\u003cli\u003eInformation Collection Requests (ICRs) if the system collects information from the public and is subject to the Paperwork Reduction Act (PRA); if unsure, please reach out to the PRA office.\u0026nbsp;\u003c/li\u003e\u003cli\u003ePrivacy Act Statements (PASs) and System of Records Notices (SORNs) if records in the system are subject to the Privacy Act;\u003c/li\u003e\u003cli\u003eAgency IT Portfolio Summaries (formerly called Exhibit 53s) or any Major IT Investment Business Cases (formerly called Exhibit 300s);\u003c/li\u003e\u003cli\u003eEnterprise Program Lifecycle Artifacts such as a System Security and Privacy Plan (SSPP); and\u003c/li\u003e\u003cli\u003eAny handbooks or other guidance on how to use the system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIt may be possible to reuse language from these documents to respond to questions. However, make sure you review all copied text to verify that it is specific to the system being reviewed, is complete, and makes sense absent the rest of the document. Text copied from marketing materials and system planning documents may discuss functions that were never purchased or implemented. Text copied from a SORN or budget document may describe more than one system.\u003c/p\u003e\u003cp\u003eThe purpose of a PIA is to provide the general public with information about how CMS systems collect and share user data. The general public is the audience for PIAs, so it’s essential to keep your end users in mind when drafting your PIA.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eAnswer each question briefly; text fields have a limited capacity when translated to the final documentation in CFACTS\u003c/li\u003e\u003cli\u003eWrite in a way that is easily understood by the general public; avoid using overly technical language, and clearly define technical terms and references if needed to describe a system.\u003c/li\u003e\u003cli\u003eDefine each acronym the first time it is used; use the acronym alone in all subsequent references.\u003c/li\u003e\u003cli\u003eDo not include sensitive or confidential system information or information that could allow a potential threat source to gain unauthorized access into the system (e.g., do not provide detailed information on technical security controls)\u003c/li\u003e\u003cli\u003eProvide information about authentication credentials. Reviewers need to know if the system is accessed using system-specific login information such as a username and password or if the system uses only PIV access and single sign-on authentication. The login method determines how user credentials are stored outside the system boundary. Please include a statement indicating whether login information is stored in the system.\u003c/li\u003e\u003cli\u003eMake it clear who the “users” are for your system. In some cases, it may be confusing whether “users” refers to individuals creating records about themselves or whether “users” are CMS staff members receiving and acting on this information. Please make this distinction clear the first time the term “users” is used. If contractors are listed as users, please cite if contractors are “direct” or “indirect”.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eGuidance for specific PIA questions\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCompleting a Privacy Impact Assessment (PIA) can be a challenge. It’s essential to provide all the relevant information while ensuring it is correct and up to date. The following guidance comes from the Privacy Office, as well as a number of ISSOs and System/Business Owners who have experience completing successful PIAs in CFACTS.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eFor PIA question 6b, make sure the ISSO information is correct and up to date.\u003c/li\u003e\u003cli\u003eWhen answering question 10, consider all changes that have occurred since the PIA was last finalized, as well as the changes that will occur when the PIA is finalized. All changes, whether or not they pose a new privacy risk, should be documented. Examples of changes include changing the physical location of a server or adding additional collection of new PII elements.\u003c/li\u003e\u003cli\u003eFor PIA question 11, you should include what HHS functions are supported by the system and how the system completes those functions. Your response should be concise and specific, and should not contain jargon or overly technical terms so that a reader with no prior knowledge of the system will understand the response. Don’t forget to spell out all acronyms on first usage.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor PIA question 12, list and describe all types of information collected by the system regardless of whether that information is considered PII. Make sure to include how long information is stored in the system. If the system holds system-specific access credentials, e.g., username, password, please describe those components in the response to this question. Specify whether the username and/or password are created by the individual, generated by the system, provided by a system administrator, or established through some other process.\u0026nbsp; Reminder: Any types of PII listed in this response also need to be listed in PIA question 15.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor PIA question 12, describe why the information listed in the question is collected. The response to this question should consider all information, whether or not it is PII. The response to this question should also specify what information is collected about each category of individual and should document and discuss if records are retrieved by PII elements.\u003c/li\u003e\u003cli\u003eFor PIA question13, include a brief description of the method of record retrieval, if you answered “Yes'' to PIA question 22 regarding System of Record Notification (SORN). Note the PII used and categories of individuals to whom the PII relates.\u0026nbsp;\u003cul\u003e\u003cli\u003eAn example is: The Physical Security System (PSS) regularly uses PII to retrieve system records including using the last name, employee ID number, and/or work phone number of CMS employees, contractors, and members of the public authorized to access the main campus and satellite offices.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003ePIA question 14 is calculated by the system. Reminder: If the response to this question is No, PIA questions 15 through 38 should no longer appear on the form.\u0026nbsp;\u003c/li\u003e\u003cli\u003eIf PIA question 15 is shown, check all the boxes that apply. If the information collected by the system is not described by any of the items in the list, there is a text field under ‘Other’ where you can list additional information. Your response should include all types of PII regardless of type sensitivity, or whether it is from employees or the public. Reminder: PII elements need to be accounted for in both PIA question 12 and PIA question 15.\u003c/li\u003e\u003cli\u003ePIA question 20 should describe all the ways Social Security Numbers (SSNS) are used in the system (if applicable). You’ll need to share when, where, and why an SSN is disclosed or shared; and why the SSN is used rather than another identifier.\u0026nbsp;\u003cul\u003e\u003cli\u003eNOTE: Employer Identification Number (EIN) also known as Federal Employer Identification Number (FEIN) or Tax Identification Number (TIN) or Federal Tax Identification Number (FTIN).\u0026nbsp; Individuals may choose to use their SSN as their EIN or FTIN. Typically, this would be sole proprietors or other small business owners who use SSN as EIN for tax purposes. EIN often appears in the format XX-XXXXXXX and may not stand out as a SSN. Any time that Social Security Numbers are involved, examine whether the collection and/or use of the SSN can be eliminated.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003eReminder: If the response to this question states that SSNs are collected, SSNs should also be listed in the response to PIA question 15.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePIA question 21 asks for the legal authorities governing information collection. Every system with PII must have an authority to collect this information. This will be a statute or Executive Order that either (a) permits or requires collection of the PII, or (b) permits or requires the underlying activity, for which it is necessary to collect PII.\u003c/li\u003e\u003cli\u003ePIA questions 22 and 22a are relevant to System of Record Notifications (SORNs). If the\u003c/li\u003e\u003cli\u003esystem uses PII to retrieve records, it may need to be covered by a SORN. Any system that has already received Privacy Office signatures should already reference a SORN. If not, you may need to seek guidance from ISPG or DSPPG to determine whether a SORN is required and in identifying an existing SORN that might apply. Please also review your response to PIA question 13 to ensure that it matches with your response here in question 22.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEach system has unique functions and answers to questions will be different for different systems. Question 23 determines whether your system needs an Information Collection Approval number from the White House Office of Management and Budget (OMB). In some cases, when you answer question 23, question 23a will appear. It asks about an OMB Information Collection Approval number. Under the Paperwork Reduction Act (PRA), the System/Business Owner or ISSO may need to obtain an information collection approval number from the OMB. Use the information in the CMS guidance and HHS PIA Writers’ Handbook regarding this question to contact subject matter experts as needed.\u003c/li\u003e\u003cli\u003eFor PIA question 27, please state that any system that utilizes information obtained from the Enterprise Portal (EIDM) must provide individuals the option to opt-out of information sharing. And similar to PIA question 25, if EIDM has its own PIA for CMS please add this statement.\u003c/li\u003e\u003cli\u003eFor PIA question 29, Identify System Acronym\u003c/li\u003e\u003cli\u003eFor PIA question 37, NARA Disposition Schedule ID, and the retention period described by the schedule, should be included\u003c/li\u003e\u003cli\u003ePIA question 37 asks about the system retention schedule. Every system (whether it contains PII or not) should have been made subject to an information retention schedule. Check with the Records Officer to identify the appropriate retention schedule.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"20:T7b99,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook defines actions that must be taken in response to a suspected breach of Personally Identifiable Information (PII) / Protected Health Information (PHI) / Federal Tax Information (FTI) at the CMS to meet federal requirements for breach response. The handbook includes roles and responsibilities, breach response deliverables and lines of communication, triggers for federal reporting requirements, and resources from HHS and other authorities.\u003c/p\u003e\u003cp\u003eThese procedures help to ensure a coordinated response from all entities responsible for investigating and mitigating a breach, including organizations internal and external to CMS, as well as those responsible for remediating any identified process shortfalls.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eScope\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThese procedures apply to federal information and information systems, as defined in the \u003ca href=\"/learn/federal-information-systems-management-act-fisma\"\u003eFederal Information Security Modernization Act (FISMA)\u003c/a\u003e – but not to national security systems.\u003c/p\u003e\u003cp\u003eThis handbook covers breach response activities at CMS as an Operating Division (OpDiv) of the U.S. Department of Health and Human Services (HHS). It applies to CMS employees, contractors, grant recipients, interns, and affiliates supporting CMS. All organizations collecting or maintaining information or using or operating information systems on behalf of CMS also need to follow these procedures in accordance with such organizations’ contractual requirements to report to and cooperate with CMS during a breach.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eOut-of-scope entities\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eMedicare Advantage (Plans C and D) and State Medicaid programs are not CMS FISMA entities but are HIPAA-covered entities. These entities must honor their own reporting requirements.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho needs this handbook?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThis handbook is for all CMS stakeholders who may need to participate in or approve of breach response activities, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePersonnel at the CMS Cybersecurity Integration Center who support CMS Incident Response (IR)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003ePeople within CMS responsible for ensuring system security and privacy – such as System Owners (SO), Information System Security Officers (ISSO), and Cyber Risk Advisors (CRA)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003ePeople at HHS who must cooperate in or approve CMS actions, including the HHS Privacy Incident Response Team (PIRT)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS Security and Privacy stakeholders who are responsible for developing cyber defense and response systems and must describe the process ecosystem for their services\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eDefinitions for incidents and breaches\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eExact reporting requirements during a breach depend on the nature of the data affected by the breach. The Office of Management and Budget (OMB) has defined multiple types of security and privacy incidents within the scope of the Executive Branch. This section presents definitions of types of sensitive data and breach categories for use at CMS.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat counts as sensitive data?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB Memorandum M-17-12 prescribes that \u003cstrong\u003ePersonally Identifiable Information\u003c/strong\u003e refers to information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual. Because there are many different types of information that can distinguish or trace an individual’s identity, the term PII is necessarily broad.\u003c/p\u003e\u003cp\u003eThe Health Insurance Portability and Accountability Act (HIPAA) provides that \u003cstrong\u003eProtected Health Information\u003c/strong\u003e is personally identifiable health information. PHI is also PII.\u003c/p\u003e\u003cp\u003eInternal Revenue Service Publication 1075 prescribes that \u003cstrong\u003eFederal Tax Information\u003c/strong\u003e consists of federal tax returns and return information (and information derived from it) that is in an agency’s possession or control. FTI may contain PII.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat is an incident?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccording to the CMS Risk Management Handbook, an\u003cstrong\u003e incident\u003c/strong\u003e is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat is a breach?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB Memorandum M-17-12 stipulates that a \u003cstrong\u003ebreach\u003c/strong\u003e is a type of incident in which there is a loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence where either of these occurs:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA person other than an authorized user accesses or potentially accesses PII\u003c/li\u003e\u003cli\u003eAn authorized user accesses PII for an other-than-authorized purpose\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBreaches begin as incidents until incident responders determine that PII has been affected. Breach activities will often take place concurrently to ongoing incident response activities, such as containment, eradication, and recovery activities. For more information about Incident Response process, see the CMS Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003cp\u003eCMS will assess suspected breaches of PII to determine if they represent enough risk of harm to individuals whose data was compromised to require notification and mitigation.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eMajor incidents\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePer OMB Memorandum M-20-04, a \u003cstrong\u003emajor incident\u003c/strong\u003e is an incident that compromises U.S. national security. CMS does not store any data that, if breached, may impact national security. OMB also defines any unauthorized modification of, unauthorized deletion of, unauthorized exfiltration of, or unauthorized access to the PII of 100,000 or more people as a major incident. Major incidents must be reported to Congress within seven days.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eReporting incidents and breaches\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eIncident responders may determine during the incident response process, as more information about an incident is discovered, that the incident falls into other incident categories that trigger additional reporting requirements.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTable of reporting triggers\u003c/strong\u003e\u003c/h3\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eTrigger\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eRequirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eOutcome\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eAll Incidents\u003c/td\u003e\u003ctd\u003eNotify HHS, notify US-CERT (Computer Emergency Response Team)\u003c/td\u003e\u003ctd\u003eHHS is automatically notified by the CMS incident ticketing system; HHS handles reporting to US-CERT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAll Suspected or Confirmed Breaches\u003c/td\u003e\u003ctd\u003eConduct Risk Assessment\u003c/td\u003e\u003ctd\u003eIf the breach is not in a predefined low-risk category, the CMS Breach Analysis Team must convene.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eGreater than 500 individuals within same jurisdiction are affected by a breach\u003c/td\u003e\u003ctd\u003eNotify media in affected jurisdiction\u003c/td\u003e\u003ctd\u003eContact CMS Media Relations Group (MRG)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach indicates illegal activity\u003c/td\u003e\u003ctd\u003eContact Law Enforcement via HHS oversight body\u003c/td\u003e\u003ctd\u003eContact HHS Office of Inspector General (OIG) Computer Crimes Unit (CCU)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach affects FTI\u003c/td\u003e\u003ctd\u003eNotify IRS and Treasury Inspector General for Tax Administration\u003c/td\u003e\u003ctd\u003eContact CMS-IRS Liaison\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eGreater than 100,000 individuals are affected by the breach (Major Incident)\u003c/td\u003e\u003ctd\u003eNotify Congress within seven days\u003c/td\u003e\u003ctd\u003eContact Office of Legislation\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch3\u003e\u003cstrong\u003eAll incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll security and privacy incidents at CMS must be reported to the CMS Information Technology (IT) Service Desk.\u003c/p\u003e\u003cul\u003e\u003cli\u003ePhone: 410-786-2580 or 800-562-1963\u003c/li\u003e\u003cli\u003eEmail: \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe report should be made immediately upon discovery to start the CMS incident response process. The IT Service Desk instructs the reporter to fill out an incident report using the Incident Report Template – which is then sent to the Incident Management Team (IMT). Incidents must be reported whether they are confirmed to have occurred or are only suspected to have occurred. The Helpdesk refers security and privacy incidents to IMT, which then coordinates efforts to analyze, contain, and eradicate the incident.\u003c/p\u003e\u003cp\u003eAll incidents involving CMS must be reported to HHS to ensure that HHS can provide accurate incident statistics for its OpDivs as per FISMA requirements. By integrating CMS’s incident ticketing system with HHS, CMS automatically notifies HHS of incidents. More details on the CMS Incident Response capability and reporting requirements for incidents other than breaches can be found in the Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAll breaches\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Incident Management Team (IMT) investigates reported security and privacy incidents to determine if they meet the definition of a breach. The team does not need confirmation of a breach to begin the breach response process – they should treat incidents as breaches as soon as the investigation reveals that PII, PHI, or FTI was jeopardized by an incident.\u003c/p\u003e\u003cp\u003eIf an incident reaches the status of a suspected breach, IMT conducts a risk assessment on the suspected breach using the Risk Assessment Checklist. Then they notify the CMS Breach Analysis Team (BAT) that a suspected breach has occurred and provide the BAT with the results of the risk assessment.\u003c/p\u003e\u003cp\u003eThe BAT convenes to review the risk assessment and determine the likelihood of sensitive data compromise according to the CMS Breach Analysis Team Handbook. The team assigns the breach a risk rating of Low, Moderate, or High, and advises the affected system’s Business Owner (BO) on whether CMS must notify the affected individuals. Should notification be necessary, the Senior Official for Privacy (SOP) at CMS works with the following people to develop a notification and mitigation plan:\u003c/p\u003e\u003cul\u003e\u003cli\u003eBusiness Owner of the CMS system affected by the breach\u003c/li\u003e\u003cli\u003eContracting Officer’s Representative (COR) for any affected contractors\u003c/li\u003e\u003cli\u003eIncident responders\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDepending on the nature and quantity of the sensitive data compromised by the breach, different reporting requirements apply:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIf a breach compromises \u003cstrong\u003ePHI/PII\u003c/strong\u003e, the HIPAA Breach Notification Rule applies.\u003c/li\u003e\u003cli\u003eIf a breach compromises \u003cstrong\u003eFTI\u003c/strong\u003e, the IRS requires that the U.S. Treasury Inspector General for Tax Administration (TIGTA) be notified.\u003c/li\u003e\u003cli\u003eIf a breach compromises any data that may impact U.S. national security or otherwise meets the definition of a \u003cstrong\u003emajor incident\u003c/strong\u003e, then Congress must be notified.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eLow risk scenarios\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSome privacy incidents are considered low risk and do not rise to the threshold of a breach. The Data Governance Board (DGB) has defined a set of criteria for such incidents in the Data Governance Board Guidelines. The IMT can close out these breaches automatically if they represent a sufficiently low risk to not require convening a full Breach Analysis Team.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreaches of PHI\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS’s administration of Medicare and Medicaid make the agency a covered entity under HIPAA and subject to the law’s reporting and notification requirements when PHI is breached. This includes reporting to the HHS Office of Civil Rights (OCR) of all breaches of Protected Health Information (PHI) for each calendar year –\u0026nbsp; including those that occur with a business associate.\u003c/p\u003e\u003cp\u003eAny compromise of PHI requires CMS to notify the affected individual(s) within 60 days. If a breach affects the PHI of more than 500 residents of a U.S. state or jurisdiction, CMS is also “required to provide notice to prominent media outlets serving the State or jurisdiction,” and notify OCR within 60 days. The Breach Analysis Team must work with the CMS Office of Communication’s Media Relations Group to complete this notification step.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreaches of FTI\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Internal Revenue Service (IRS) requires organizations handling FTI (federal tax returns and return information, including information derived from a return) to report any unauthorized access to or disclosure of FTI to the Treasury Inspector General for Tax Administration and the IRS Office of Safeguards within 24 hours of identifying the incident.\u003c/p\u003e\u003cp\u003eIf the Incident Management Team (IMT)\u0026nbsp; determines that there is a possibility that FTI has been compromised by an incident, they should immediately notify the CMS IRS Liaison to begin the process for reporting to the IRS and TIGTA. Breach response stakeholders should be aware that IRS may request additional data and updates from CMS as the incident response process continues.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMajor incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB requires agencies to report major incidents to Congress within seven days. The threshold for a major incident is a breach that affects more than 100,000 individuals. As an HHS OpDiv, CMS will report major incidents to the HHS Computer Security Incident Response Center (CSIRC) to assist HHS in making a report to Congress. CMS will also report major incidents to the CMS Office of Legislation to ensure that the Office can coordinate with HHS on any participation by CMS in the report.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eBreach response steps and deliverables\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBreach response activities at CMS require robust lines of communication and clearly defined deliverables between multiple organizations and components, including CMS groups, contractors and associates, and HHS entities.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIn general, the communication responsibilities of CMS, HHS, and entities are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS will be responsible for collecting data pertaining to the breach, developing a plan for notifying persons affected by the breach and mitigating any resulting harm, and reporting all breach response activities to HHS.\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eHHS will be responsible for coordinating between CMS and external federal agencies, as well as approving any notification and mitigation plans developed by CMS.\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eEntities operating on behalf of CMS (contractors and associates) are responsible for implementing notification and mitigation plans created by CMS and approved by HHS.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBreach response activities take place in tandem with incident response activities. Discovery of new data about a breach should be reported as soon as possible to HHS Computer Security Incident Response Center (CSIRC), to ensure that HHS can meet its own reporting requirements. (HHS CSIRC is the primary communication pathway between CMS and external organizations such as other federal agencies.)\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS maintains an incident ticketing system that automatically sends ticket updates to a mirrored ticket in the equivalent HHS CSIRC ticketing system. Incident responders must maintain this integration and ensure that tickets are promptly updated to communicate with HHS.\u003c/p\u003e\u003cp\u003eThe Incident Management Team, in keeping with its role during incident response, is the primary communication pathway between organizations within CMS and its contractors and associates. For more details on IMT’s role and process during incidents, see the CMS Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003cp\u003eBreach response activities are accomplished through four stages: reporting, risk assessment, breach analysis, and notification and mitigation.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eReporting\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe incident ticket submitted by the CMS IT Helpdesk is the first notice to CMS of a possible breach. The IT Helpdesk works with the individual reporting an incident to create an initial \u003cstrong\u003eincident report as a deliverable\u003c/strong\u003e to the Incident Management Team (IMT) and create a ticket to track the issue. The incident ticket is automatically mirrored in the equivalent HHS system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRisk assessment\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIMT works with the affected system’s officials and operators to investigate the incident. They assess the incident to determine if any categories of sensitive data may be compromised. If there is a possibility of compromise, the incident is considered a suspected breach. IMT conducts a risk assessment using the “Factors for Assessing the Risk of Harm to Potentially Affected Individuals” prescribed by OMB and defined in the CMS Risk Assessment for Breach Notification Determination form. Then they formally convene the Breach Analysis Team and provide the team with the\u003cstrong\u003e IMT Risk Assessment as a deliverable.\u003c/strong\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreach analysis\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Breach Analysis Team convenes to review the IMT Risk Assessment and categorizes the risk represented by the breach as low, moderate, or high, as described in the CMS Breach Analysis Team Handbook.\u003c/p\u003e\u003cp\u003eThe BAT consists of breach response stakeholders in leadership positions and security and privacy subject matter experts for the affected system, including the Business Owner, ISSOs, COR (if the affected system is a contractor system), Senior Official for Privacy, and the DCTSO Incident Commander.\u003c/p\u003e\u003cp\u003eThe BAT determines if the conditions of the breach warrant notifying the affected individuals. If so, the BAT drafts a \u003cstrong\u003eNotification and Mitigation Plan as a deliverable\u003c/strong\u003e to the HHS Privacy Incident Response Team (PIRT), using the HHS PIRT Response Plan Template. The Business Owner of the affected system has the final decision on whether notification and mitigation will go forward.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNotification and mitigation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eHHS PIRT reviews the Notification and Mitigation Plan. The PIRT may overrule the BAT on whether notification and mitigation are necessary or they may request changes to the plan. If the PIRT approves, the Business Owner of the affected system (and the COR if the affected system is a contractor system) are responsible for executing the approved plan.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTable of breach response deliverables\u003c/strong\u003e\u003c/h3\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eBreach Response Deliverable\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eResponsible\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eDelivered To\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eIncident Report Ticket\u003c/td\u003e\u003ctd\u003eCMS IT Helpdesk\u003c/td\u003e\u003ctd\u003eIncident Management Team (IMT). IMT continues to update the ticket with information about the breach as the response proceeds.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk Assessment\u003c/td\u003e\u003ctd\u003eIncident Management Team\u003c/td\u003e\u003ctd\u003eBreach Analysis Team (BAT)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eNotification and Mitigation Plan\u003c/td\u003e\u003ctd\u003eBreach Analysis Team\u003c/td\u003e\u003ctd\u003eHHS Privacy Incident Response Team (PIRT)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach Notification to Affected Individuals\u003c/td\u003e\u003ctd\u003eSystem Business Owner / Contracting Officer’s Representative\u003c/td\u003e\u003ctd\u003eAffected individuals\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch2\u003e\u003cstrong\u003eBreach notification and mitigation\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe goal of breach response activities is to reduce the risk of harm to individuals that is created by a breach of sensitive data. If the Breach Analysis Team determines that a breach represents enough risk to individuals, they develop a Notification and Mitigation Plan.\u003c/p\u003e\u003cp\u003eThe CMS Senior Official for Privacy, in cooperation with the Business Owner of the affected system and with support from the full BAT, is responsible for developing the Notification and Mitigation Plan. CMS will receive approval to implement the plan from the HHS PIRT, using the HHS PIRT Response Plan Template as the formal deliverable. The Notification and Mitigation Plan must consider the nature and scope of the breach to determine if media organizations must be notified as per the HIPAA requirements.\u003c/p\u003e\u003cp\u003eOnce approved, the Notification and Mitigation Plan is implemented, with responsibility for implementation assigned to the Business Owner of the affected system (or the COR, if the affected system is a contractor system). If media notification is required, the BAT should coordinate with the CMS Media Relations Group (MRG).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNotification\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIf the Breach Analysis Team determines that a breach of PII represents a risk of harm to the affected individuals, then CMS must notify individuals whose PII is compromised in a breach. The team will develop a Notification and Mitigation Plan to describe the actions CMS will take to protect the affected individuals.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eIndividual notification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAs prescribed by the \u003ca href=\"/policy-guidance/breach-analysis-team-bat-handbook\"\u003eCMS Breach Analysis Team Handbook\u003c/a\u003e, the CMS Senior Official for Privacy works with the Business Owner of an affected CMS system to develop a notification letter describing the breach for individuals and submit it to HHS PIRT for approval.\u003c/p\u003e\u003cp\u003eOMB M-17-12 provides direction to federal agencies on what information should be included in breach notifications:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA brief description of what happened, including the date(s) of the breach and of its discovery\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA description of the types of sensitive data compromised by the breach (e.g., full name, Social Security Number, date of birth, home address, account number, and disability code), to the extent possible\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA statement of whether the information was encrypted or protected by other means, when it is determined that disclosing such information would be beneficial to potentially affected individuals and would not compromise the security of the information system\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eGuidance to potentially affected individuals on how they can mitigate their own risk of harm, the countermeasures undertaken, and any services provided to potentially affected individuals\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAny steps being taken to investigate the breach, to mitigate losses, and to protect against a future breach\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA description of how potentially affected individuals can learn more information about the breach, including a telephone number (preferably toll-free), email address, and postal address\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eHHS PIRT has oversight over CMS breach notification plans. After developing the notification letter and a plan to contact the affected individuals, the BAT should meet with HHS PIRT to gain approval to implement the plan. This meeting should also be attended by the Business Owner(s) of any affected CMS systems, the Contracting Officers of any CMS contractor partners who were involved in the breach, and the incident response personnel who investigated the breach to ensure that HHS PIRT can receive timely answers to any questions related to the breach.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eMedia notification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIn addition to individual notification, HIPAA requires CMS to notify local media outlets if a breach of PHI affects more than 500 individuals within a single locality.\u0026nbsp; The Breach Analysis Team should contact CMS Media Relations Group if a breach of PII/PHI affects more than 500 individuals to make certain that any plans to contact media outlets are included in the notification plan submitted to HHS PIRT for approval.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNotification through public CMS resources\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS must also consider that a widely publicized breach may cause members of the public to attempt to contact CMS with questions about the breach and inquire whether their own information was affected. As part of the notification plan, the Breach Analysis Team may determine that CMS should provide a public notification message on its public resources, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePosting on the cms.gov homepage to inform the public of the breach, with a link to further details\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eProviding CMS call centers with a message to play at the start of calls to inform callers how they can determine if they were affected by a breach\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eMitigation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAs part of its notification plan, the Breach Analysis Team must determine and document the actions that CMS will take to mitigate the risk of harm. If the breach puts the affected individuals at risk for identity theft, CMS will offer credit monitoring as prescribed by the CMS Breach Analysis Team Handbook.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eBudgeting considerations\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThere may be costs associated with implementing a notification and mitigation plan, such as providing a credit monitoring service free of charge to the affected individuals. If a contractor system is breached, the contractor should cover the costs of notification and mitigation. CMS contracts should establish this responsibility.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRoles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBreach response stakeholders have direct or supporting roles and responsibilities during a breach. Some stakeholders in this group are associated with the FISMA system undergoing a breach and some are part of the CMS incident response capability. The breach response stakeholders have the following roles and responsibilities:\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCMS FISMA System Stakeholders\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eBusiness Owner (BO)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns decision to notify individuals affected by a breach and provide mitigation, with advisement from the BAT.\u003c/li\u003e\u003cli\u003eOwns decision to take major actions impacting system availability in response to a breach (such as shutting down a breached system).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003ePrimary Information System Security Officer (ISSO)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrimary system stakeholder in charge of providing data to IMT, BAT, and other breach response stakeholders about the affected system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOperations Teams (to include General Support System [GSS] support)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eTakes incident response actions on the system affected by the breach. May escalate decision to take major action impacting availability to the BO.\u003c/li\u003e\u003cli\u003eProvides system data to IMT, BAT and other breach response stakeholders at the direction of the ISSO.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCyber Risk Adviser (CRA)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides guidance to breach response stakeholders on risk and compliance for the affected system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eISPG Breach Response and Coordination\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eCMS CISO\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the breach response process.\u003c/li\u003e\u003cli\u003eIs kept apprised of all developments during breach response, analysis, notification, and mitigation.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCMS Senior Official for Privacy (SOP)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the Breach Analysis Team process.\u003c/li\u003e\u003cli\u003eOwns and oversees the Notification and Mitigation Plan, in cooperation with the system BO.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDCTSO Incident Coordinator\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the incident response process.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Cybersecurity Integration Center (CCIC)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eIncident Management Team (IMT)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrimary coordination entity for breach response. Works to provide leadership (BAT, senior officials) with data about the breach to make decisions.\u003c/li\u003e\u003cli\u003eConducts initial analysis and risk assessment of breaches to provide to the BAT.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCMS Security Operations Center (SOC)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides technical support and security subject matter expertise to the BAT during a breach.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Subject Matter Expert Support\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eCMS Office of Communications/Media Relations Group\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides notification to media outlets in the event of a breach affecting the PHI of more than 500 individuals.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOffice of General Counsel\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides support to the BAT in the event of a major incident to help CMS prepare for congressional notification.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eBreach Analysis Team (BAT)\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003eOwns the risk decision (low/moderate/high) after IMT conducts a risk assessment.\u003c/li\u003e\u003cli\u003eWorks with the SOP and BO to advise on the Notification and Mitigation Plan.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eLaws and guidance\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eUse this list of applicable laws and guidance to learn more about the processes described in this handbook.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFederal laws\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.congress.gov/113/plaws/publ283/PLAW-113publ283.pdf\"\u003eFederal Information Security Modernization Act\u003c/a\u003e (FISMA) of 2014, Pub. L. 113-283, 128 Stat. 3073 (Dec. 18, 2014) (primarily codified at 44 U.S.C. chapter 35, subchapter 11).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.congress.gov/104/plaws/publ191/PLAW-104publ191.pdf\"\u003eHealth Insurance Portability and Accountability Act\u003c/a\u003e (HIPAA) of 1996, Pub. L. 104-191 (Aug. 21, 1996).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eExecutive orders, memoranda, and directives\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2017/m-17-12_0.pdf\"\u003eOMB Memorandum M-17-12\u003c/a\u003e, Preparing for and Responding to a Breach of Personally Identifiable Information (January 3, 2017).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.whitehouse.gov/wp-content/uploads/2019/11/M-20-04.pdf\"\u003eOMB Memorandum M-20-04\u003c/a\u003e, Fiscal Year 2019-2020 Guidance on Federal Information Security and Privacy Management Requirements (November 19, 2019).\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf\"\u003eOMB Circular A-130, Managing Information as a Strategic Resource\u003c/a\u003e (July 28, 2016).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/the-press-office/2016/07/26/annex-presidential-policy-directive-united-states-cyber-incident\"\u003ePPD-41, Annex for Presidential Policy Directive\u003c/a\u003e – United States Cyber Incident Coordination (July 26, 2016).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/memoranda/2016/m-16-14.pdf\"\u003eOMB Memorandum M-16-14, Category Management Policy 16-2\u003c/a\u003e: Providing Comprehensive Identity Protection Services, Identity Monitoring, and Data Breach Response (July 1, 2016).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS / HHS policy and procedures\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003eCMS Risk Management Handbook (RMH) Chapter 8: Incident Response\u003c/li\u003e\u003cli\u003eCMS Breach Analysis Team Handbook\u003c/li\u003e\u003cli\u003eData Governance Guidelines\u003c/li\u003e\u003cli\u003eHHS PIRT Response Plan Template\u003c/li\u003e\u003cli\u003eCMS Risk Assessment for Breach Notification Determination\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAdditional guidance\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eDepartment of Commerce / National Institute of Standards and Technology (NIST)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eNIST Special Publication 800-34 (Revision 1), \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf\"\u003eContingency Planning Guide for Federal Information Systems and Organizations\u003c/a\u003e (Apr. 2013).\u0026nbsp;\u003c/li\u003e\u003cli\u003eNIST Special Publication 800-61 (Revision 2), \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf\"\u003eComputer Security Incident Handling Guide\u003c/a\u003e (Aug. 2012).\u0026nbsp;\u003c/li\u003e\u003cli\u003eNIST Special Publication 800-122, \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf\"\u003eGuide to Protecting the Confidentiality of PII\u003c/a\u003e (Apr. 2010).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDepartment of Homeland Security (DHS) / United States Computer Emergency Readiness Team (US-CERT)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.cisa.gov/uscert/incident-notification-guidelines\"\u003eUS-CERT Federal Incident Notification Guidelines\u003c/a\u003e\u003c/li\u003e\u003cli\u003eNational Cybersecurity and Communications Integration Center (NCCIC) \u003ca href=\"https://www.cisa.gov/uscert/CISA-National-Cyber-Incident-Scoring-System\"\u003eCyber Incident Scoring System\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eGeneral Services Administration (GSA)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.gsa.gov/buy-through-us/products-services/professional-services/buy-services/identity-protection-services-ips\"\u003eIdentity Protection Services (IPS) Multiple Award Blanket Purchase Agreement (BPA)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"21:T7b99,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook defines actions that must be taken in response to a suspected breach of Personally Identifiable Information (PII) / Protected Health Information (PHI) / Federal Tax Information (FTI) at the CMS to meet federal requirements for breach response. The handbook includes roles and responsibilities, breach response deliverables and lines of communication, triggers for federal reporting requirements, and resources from HHS and other authorities.\u003c/p\u003e\u003cp\u003eThese procedures help to ensure a coordinated response from all entities responsible for investigating and mitigating a breach, including organizations internal and external to CMS, as well as those responsible for remediating any identified process shortfalls.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eScope\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThese procedures apply to federal information and information systems, as defined in the \u003ca href=\"/learn/federal-information-systems-management-act-fisma\"\u003eFederal Information Security Modernization Act (FISMA)\u003c/a\u003e – but not to national security systems.\u003c/p\u003e\u003cp\u003eThis handbook covers breach response activities at CMS as an Operating Division (OpDiv) of the U.S. Department of Health and Human Services (HHS). It applies to CMS employees, contractors, grant recipients, interns, and affiliates supporting CMS. All organizations collecting or maintaining information or using or operating information systems on behalf of CMS also need to follow these procedures in accordance with such organizations’ contractual requirements to report to and cooperate with CMS during a breach.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eOut-of-scope entities\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eMedicare Advantage (Plans C and D) and State Medicaid programs are not CMS FISMA entities but are HIPAA-covered entities. These entities must honor their own reporting requirements.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho needs this handbook?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThis handbook is for all CMS stakeholders who may need to participate in or approve of breach response activities, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePersonnel at the CMS Cybersecurity Integration Center who support CMS Incident Response (IR)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003ePeople within CMS responsible for ensuring system security and privacy – such as System Owners (SO), Information System Security Officers (ISSO), and Cyber Risk Advisors (CRA)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003ePeople at HHS who must cooperate in or approve CMS actions, including the HHS Privacy Incident Response Team (PIRT)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS Security and Privacy stakeholders who are responsible for developing cyber defense and response systems and must describe the process ecosystem for their services\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eDefinitions for incidents and breaches\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eExact reporting requirements during a breach depend on the nature of the data affected by the breach. The Office of Management and Budget (OMB) has defined multiple types of security and privacy incidents within the scope of the Executive Branch. This section presents definitions of types of sensitive data and breach categories for use at CMS.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat counts as sensitive data?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB Memorandum M-17-12 prescribes that \u003cstrong\u003ePersonally Identifiable Information\u003c/strong\u003e refers to information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual. Because there are many different types of information that can distinguish or trace an individual’s identity, the term PII is necessarily broad.\u003c/p\u003e\u003cp\u003eThe Health Insurance Portability and Accountability Act (HIPAA) provides that \u003cstrong\u003eProtected Health Information\u003c/strong\u003e is personally identifiable health information. PHI is also PII.\u003c/p\u003e\u003cp\u003eInternal Revenue Service Publication 1075 prescribes that \u003cstrong\u003eFederal Tax Information\u003c/strong\u003e consists of federal tax returns and return information (and information derived from it) that is in an agency’s possession or control. FTI may contain PII.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat is an incident?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccording to the CMS Risk Management Handbook, an\u003cstrong\u003e incident\u003c/strong\u003e is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat is a breach?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB Memorandum M-17-12 stipulates that a \u003cstrong\u003ebreach\u003c/strong\u003e is a type of incident in which there is a loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence where either of these occurs:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA person other than an authorized user accesses or potentially accesses PII\u003c/li\u003e\u003cli\u003eAn authorized user accesses PII for an other-than-authorized purpose\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBreaches begin as incidents until incident responders determine that PII has been affected. Breach activities will often take place concurrently to ongoing incident response activities, such as containment, eradication, and recovery activities. For more information about Incident Response process, see the CMS Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003cp\u003eCMS will assess suspected breaches of PII to determine if they represent enough risk of harm to individuals whose data was compromised to require notification and mitigation.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eMajor incidents\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePer OMB Memorandum M-20-04, a \u003cstrong\u003emajor incident\u003c/strong\u003e is an incident that compromises U.S. national security. CMS does not store any data that, if breached, may impact national security. OMB also defines any unauthorized modification of, unauthorized deletion of, unauthorized exfiltration of, or unauthorized access to the PII of 100,000 or more people as a major incident. Major incidents must be reported to Congress within seven days.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eReporting incidents and breaches\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eIncident responders may determine during the incident response process, as more information about an incident is discovered, that the incident falls into other incident categories that trigger additional reporting requirements.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTable of reporting triggers\u003c/strong\u003e\u003c/h3\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eTrigger\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eRequirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eOutcome\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eAll Incidents\u003c/td\u003e\u003ctd\u003eNotify HHS, notify US-CERT (Computer Emergency Response Team)\u003c/td\u003e\u003ctd\u003eHHS is automatically notified by the CMS incident ticketing system; HHS handles reporting to US-CERT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAll Suspected or Confirmed Breaches\u003c/td\u003e\u003ctd\u003eConduct Risk Assessment\u003c/td\u003e\u003ctd\u003eIf the breach is not in a predefined low-risk category, the CMS Breach Analysis Team must convene.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eGreater than 500 individuals within same jurisdiction are affected by a breach\u003c/td\u003e\u003ctd\u003eNotify media in affected jurisdiction\u003c/td\u003e\u003ctd\u003eContact CMS Media Relations Group (MRG)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach indicates illegal activity\u003c/td\u003e\u003ctd\u003eContact Law Enforcement via HHS oversight body\u003c/td\u003e\u003ctd\u003eContact HHS Office of Inspector General (OIG) Computer Crimes Unit (CCU)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach affects FTI\u003c/td\u003e\u003ctd\u003eNotify IRS and Treasury Inspector General for Tax Administration\u003c/td\u003e\u003ctd\u003eContact CMS-IRS Liaison\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eGreater than 100,000 individuals are affected by the breach (Major Incident)\u003c/td\u003e\u003ctd\u003eNotify Congress within seven days\u003c/td\u003e\u003ctd\u003eContact Office of Legislation\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch3\u003e\u003cstrong\u003eAll incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll security and privacy incidents at CMS must be reported to the CMS Information Technology (IT) Service Desk.\u003c/p\u003e\u003cul\u003e\u003cli\u003ePhone: 410-786-2580 or 800-562-1963\u003c/li\u003e\u003cli\u003eEmail: \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe report should be made immediately upon discovery to start the CMS incident response process. The IT Service Desk instructs the reporter to fill out an incident report using the Incident Report Template – which is then sent to the Incident Management Team (IMT). Incidents must be reported whether they are confirmed to have occurred or are only suspected to have occurred. The Helpdesk refers security and privacy incidents to IMT, which then coordinates efforts to analyze, contain, and eradicate the incident.\u003c/p\u003e\u003cp\u003eAll incidents involving CMS must be reported to HHS to ensure that HHS can provide accurate incident statistics for its OpDivs as per FISMA requirements. By integrating CMS’s incident ticketing system with HHS, CMS automatically notifies HHS of incidents. More details on the CMS Incident Response capability and reporting requirements for incidents other than breaches can be found in the Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAll breaches\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Incident Management Team (IMT) investigates reported security and privacy incidents to determine if they meet the definition of a breach. The team does not need confirmation of a breach to begin the breach response process – they should treat incidents as breaches as soon as the investigation reveals that PII, PHI, or FTI was jeopardized by an incident.\u003c/p\u003e\u003cp\u003eIf an incident reaches the status of a suspected breach, IMT conducts a risk assessment on the suspected breach using the Risk Assessment Checklist. Then they notify the CMS Breach Analysis Team (BAT) that a suspected breach has occurred and provide the BAT with the results of the risk assessment.\u003c/p\u003e\u003cp\u003eThe BAT convenes to review the risk assessment and determine the likelihood of sensitive data compromise according to the CMS Breach Analysis Team Handbook. The team assigns the breach a risk rating of Low, Moderate, or High, and advises the affected system’s Business Owner (BO) on whether CMS must notify the affected individuals. Should notification be necessary, the Senior Official for Privacy (SOP) at CMS works with the following people to develop a notification and mitigation plan:\u003c/p\u003e\u003cul\u003e\u003cli\u003eBusiness Owner of the CMS system affected by the breach\u003c/li\u003e\u003cli\u003eContracting Officer’s Representative (COR) for any affected contractors\u003c/li\u003e\u003cli\u003eIncident responders\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDepending on the nature and quantity of the sensitive data compromised by the breach, different reporting requirements apply:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIf a breach compromises \u003cstrong\u003ePHI/PII\u003c/strong\u003e, the HIPAA Breach Notification Rule applies.\u003c/li\u003e\u003cli\u003eIf a breach compromises \u003cstrong\u003eFTI\u003c/strong\u003e, the IRS requires that the U.S. Treasury Inspector General for Tax Administration (TIGTA) be notified.\u003c/li\u003e\u003cli\u003eIf a breach compromises any data that may impact U.S. national security or otherwise meets the definition of a \u003cstrong\u003emajor incident\u003c/strong\u003e, then Congress must be notified.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eLow risk scenarios\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSome privacy incidents are considered low risk and do not rise to the threshold of a breach. The Data Governance Board (DGB) has defined a set of criteria for such incidents in the Data Governance Board Guidelines. The IMT can close out these breaches automatically if they represent a sufficiently low risk to not require convening a full Breach Analysis Team.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreaches of PHI\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS’s administration of Medicare and Medicaid make the agency a covered entity under HIPAA and subject to the law’s reporting and notification requirements when PHI is breached. This includes reporting to the HHS Office of Civil Rights (OCR) of all breaches of Protected Health Information (PHI) for each calendar year –\u0026nbsp; including those that occur with a business associate.\u003c/p\u003e\u003cp\u003eAny compromise of PHI requires CMS to notify the affected individual(s) within 60 days. If a breach affects the PHI of more than 500 residents of a U.S. state or jurisdiction, CMS is also “required to provide notice to prominent media outlets serving the State or jurisdiction,” and notify OCR within 60 days. The Breach Analysis Team must work with the CMS Office of Communication’s Media Relations Group to complete this notification step.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreaches of FTI\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Internal Revenue Service (IRS) requires organizations handling FTI (federal tax returns and return information, including information derived from a return) to report any unauthorized access to or disclosure of FTI to the Treasury Inspector General for Tax Administration and the IRS Office of Safeguards within 24 hours of identifying the incident.\u003c/p\u003e\u003cp\u003eIf the Incident Management Team (IMT)\u0026nbsp; determines that there is a possibility that FTI has been compromised by an incident, they should immediately notify the CMS IRS Liaison to begin the process for reporting to the IRS and TIGTA. Breach response stakeholders should be aware that IRS may request additional data and updates from CMS as the incident response process continues.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMajor incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB requires agencies to report major incidents to Congress within seven days. The threshold for a major incident is a breach that affects more than 100,000 individuals. As an HHS OpDiv, CMS will report major incidents to the HHS Computer Security Incident Response Center (CSIRC) to assist HHS in making a report to Congress. CMS will also report major incidents to the CMS Office of Legislation to ensure that the Office can coordinate with HHS on any participation by CMS in the report.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eBreach response steps and deliverables\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBreach response activities at CMS require robust lines of communication and clearly defined deliverables between multiple organizations and components, including CMS groups, contractors and associates, and HHS entities.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIn general, the communication responsibilities of CMS, HHS, and entities are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS will be responsible for collecting data pertaining to the breach, developing a plan for notifying persons affected by the breach and mitigating any resulting harm, and reporting all breach response activities to HHS.\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eHHS will be responsible for coordinating between CMS and external federal agencies, as well as approving any notification and mitigation plans developed by CMS.\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eEntities operating on behalf of CMS (contractors and associates) are responsible for implementing notification and mitigation plans created by CMS and approved by HHS.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBreach response activities take place in tandem with incident response activities. Discovery of new data about a breach should be reported as soon as possible to HHS Computer Security Incident Response Center (CSIRC), to ensure that HHS can meet its own reporting requirements. (HHS CSIRC is the primary communication pathway between CMS and external organizations such as other federal agencies.)\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS maintains an incident ticketing system that automatically sends ticket updates to a mirrored ticket in the equivalent HHS CSIRC ticketing system. Incident responders must maintain this integration and ensure that tickets are promptly updated to communicate with HHS.\u003c/p\u003e\u003cp\u003eThe Incident Management Team, in keeping with its role during incident response, is the primary communication pathway between organizations within CMS and its contractors and associates. For more details on IMT’s role and process during incidents, see the CMS Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003cp\u003eBreach response activities are accomplished through four stages: reporting, risk assessment, breach analysis, and notification and mitigation.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eReporting\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe incident ticket submitted by the CMS IT Helpdesk is the first notice to CMS of a possible breach. The IT Helpdesk works with the individual reporting an incident to create an initial \u003cstrong\u003eincident report as a deliverable\u003c/strong\u003e to the Incident Management Team (IMT) and create a ticket to track the issue. The incident ticket is automatically mirrored in the equivalent HHS system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRisk assessment\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIMT works with the affected system’s officials and operators to investigate the incident. They assess the incident to determine if any categories of sensitive data may be compromised. If there is a possibility of compromise, the incident is considered a suspected breach. IMT conducts a risk assessment using the “Factors for Assessing the Risk of Harm to Potentially Affected Individuals” prescribed by OMB and defined in the CMS Risk Assessment for Breach Notification Determination form. Then they formally convene the Breach Analysis Team and provide the team with the\u003cstrong\u003e IMT Risk Assessment as a deliverable.\u003c/strong\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreach analysis\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Breach Analysis Team convenes to review the IMT Risk Assessment and categorizes the risk represented by the breach as low, moderate, or high, as described in the CMS Breach Analysis Team Handbook.\u003c/p\u003e\u003cp\u003eThe BAT consists of breach response stakeholders in leadership positions and security and privacy subject matter experts for the affected system, including the Business Owner, ISSOs, COR (if the affected system is a contractor system), Senior Official for Privacy, and the DCTSO Incident Commander.\u003c/p\u003e\u003cp\u003eThe BAT determines if the conditions of the breach warrant notifying the affected individuals. If so, the BAT drafts a \u003cstrong\u003eNotification and Mitigation Plan as a deliverable\u003c/strong\u003e to the HHS Privacy Incident Response Team (PIRT), using the HHS PIRT Response Plan Template. The Business Owner of the affected system has the final decision on whether notification and mitigation will go forward.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNotification and mitigation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eHHS PIRT reviews the Notification and Mitigation Plan. The PIRT may overrule the BAT on whether notification and mitigation are necessary or they may request changes to the plan. If the PIRT approves, the Business Owner of the affected system (and the COR if the affected system is a contractor system) are responsible for executing the approved plan.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTable of breach response deliverables\u003c/strong\u003e\u003c/h3\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eBreach Response Deliverable\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eResponsible\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eDelivered To\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eIncident Report Ticket\u003c/td\u003e\u003ctd\u003eCMS IT Helpdesk\u003c/td\u003e\u003ctd\u003eIncident Management Team (IMT). IMT continues to update the ticket with information about the breach as the response proceeds.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk Assessment\u003c/td\u003e\u003ctd\u003eIncident Management Team\u003c/td\u003e\u003ctd\u003eBreach Analysis Team (BAT)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eNotification and Mitigation Plan\u003c/td\u003e\u003ctd\u003eBreach Analysis Team\u003c/td\u003e\u003ctd\u003eHHS Privacy Incident Response Team (PIRT)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach Notification to Affected Individuals\u003c/td\u003e\u003ctd\u003eSystem Business Owner / Contracting Officer’s Representative\u003c/td\u003e\u003ctd\u003eAffected individuals\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch2\u003e\u003cstrong\u003eBreach notification and mitigation\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe goal of breach response activities is to reduce the risk of harm to individuals that is created by a breach of sensitive data. If the Breach Analysis Team determines that a breach represents enough risk to individuals, they develop a Notification and Mitigation Plan.\u003c/p\u003e\u003cp\u003eThe CMS Senior Official for Privacy, in cooperation with the Business Owner of the affected system and with support from the full BAT, is responsible for developing the Notification and Mitigation Plan. CMS will receive approval to implement the plan from the HHS PIRT, using the HHS PIRT Response Plan Template as the formal deliverable. The Notification and Mitigation Plan must consider the nature and scope of the breach to determine if media organizations must be notified as per the HIPAA requirements.\u003c/p\u003e\u003cp\u003eOnce approved, the Notification and Mitigation Plan is implemented, with responsibility for implementation assigned to the Business Owner of the affected system (or the COR, if the affected system is a contractor system). If media notification is required, the BAT should coordinate with the CMS Media Relations Group (MRG).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNotification\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIf the Breach Analysis Team determines that a breach of PII represents a risk of harm to the affected individuals, then CMS must notify individuals whose PII is compromised in a breach. The team will develop a Notification and Mitigation Plan to describe the actions CMS will take to protect the affected individuals.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eIndividual notification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAs prescribed by the \u003ca href=\"/policy-guidance/breach-analysis-team-bat-handbook\"\u003eCMS Breach Analysis Team Handbook\u003c/a\u003e, the CMS Senior Official for Privacy works with the Business Owner of an affected CMS system to develop a notification letter describing the breach for individuals and submit it to HHS PIRT for approval.\u003c/p\u003e\u003cp\u003eOMB M-17-12 provides direction to federal agencies on what information should be included in breach notifications:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA brief description of what happened, including the date(s) of the breach and of its discovery\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA description of the types of sensitive data compromised by the breach (e.g., full name, Social Security Number, date of birth, home address, account number, and disability code), to the extent possible\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA statement of whether the information was encrypted or protected by other means, when it is determined that disclosing such information would be beneficial to potentially affected individuals and would not compromise the security of the information system\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eGuidance to potentially affected individuals on how they can mitigate their own risk of harm, the countermeasures undertaken, and any services provided to potentially affected individuals\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAny steps being taken to investigate the breach, to mitigate losses, and to protect against a future breach\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA description of how potentially affected individuals can learn more information about the breach, including a telephone number (preferably toll-free), email address, and postal address\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eHHS PIRT has oversight over CMS breach notification plans. After developing the notification letter and a plan to contact the affected individuals, the BAT should meet with HHS PIRT to gain approval to implement the plan. This meeting should also be attended by the Business Owner(s) of any affected CMS systems, the Contracting Officers of any CMS contractor partners who were involved in the breach, and the incident response personnel who investigated the breach to ensure that HHS PIRT can receive timely answers to any questions related to the breach.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eMedia notification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIn addition to individual notification, HIPAA requires CMS to notify local media outlets if a breach of PHI affects more than 500 individuals within a single locality.\u0026nbsp; The Breach Analysis Team should contact CMS Media Relations Group if a breach of PII/PHI affects more than 500 individuals to make certain that any plans to contact media outlets are included in the notification plan submitted to HHS PIRT for approval.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNotification through public CMS resources\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS must also consider that a widely publicized breach may cause members of the public to attempt to contact CMS with questions about the breach and inquire whether their own information was affected. As part of the notification plan, the Breach Analysis Team may determine that CMS should provide a public notification message on its public resources, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePosting on the cms.gov homepage to inform the public of the breach, with a link to further details\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eProviding CMS call centers with a message to play at the start of calls to inform callers how they can determine if they were affected by a breach\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eMitigation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAs part of its notification plan, the Breach Analysis Team must determine and document the actions that CMS will take to mitigate the risk of harm. If the breach puts the affected individuals at risk for identity theft, CMS will offer credit monitoring as prescribed by the CMS Breach Analysis Team Handbook.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eBudgeting considerations\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThere may be costs associated with implementing a notification and mitigation plan, such as providing a credit monitoring service free of charge to the affected individuals. If a contractor system is breached, the contractor should cover the costs of notification and mitigation. CMS contracts should establish this responsibility.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRoles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBreach response stakeholders have direct or supporting roles and responsibilities during a breach. Some stakeholders in this group are associated with the FISMA system undergoing a breach and some are part of the CMS incident response capability. The breach response stakeholders have the following roles and responsibilities:\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCMS FISMA System Stakeholders\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eBusiness Owner (BO)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns decision to notify individuals affected by a breach and provide mitigation, with advisement from the BAT.\u003c/li\u003e\u003cli\u003eOwns decision to take major actions impacting system availability in response to a breach (such as shutting down a breached system).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003ePrimary Information System Security Officer (ISSO)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrimary system stakeholder in charge of providing data to IMT, BAT, and other breach response stakeholders about the affected system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOperations Teams (to include General Support System [GSS] support)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eTakes incident response actions on the system affected by the breach. May escalate decision to take major action impacting availability to the BO.\u003c/li\u003e\u003cli\u003eProvides system data to IMT, BAT and other breach response stakeholders at the direction of the ISSO.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCyber Risk Adviser (CRA)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides guidance to breach response stakeholders on risk and compliance for the affected system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eISPG Breach Response and Coordination\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eCMS CISO\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the breach response process.\u003c/li\u003e\u003cli\u003eIs kept apprised of all developments during breach response, analysis, notification, and mitigation.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCMS Senior Official for Privacy (SOP)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the Breach Analysis Team process.\u003c/li\u003e\u003cli\u003eOwns and oversees the Notification and Mitigation Plan, in cooperation with the system BO.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDCTSO Incident Coordinator\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the incident response process.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Cybersecurity Integration Center (CCIC)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eIncident Management Team (IMT)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrimary coordination entity for breach response. Works to provide leadership (BAT, senior officials) with data about the breach to make decisions.\u003c/li\u003e\u003cli\u003eConducts initial analysis and risk assessment of breaches to provide to the BAT.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCMS Security Operations Center (SOC)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides technical support and security subject matter expertise to the BAT during a breach.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Subject Matter Expert Support\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eCMS Office of Communications/Media Relations Group\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides notification to media outlets in the event of a breach affecting the PHI of more than 500 individuals.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOffice of General Counsel\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides support to the BAT in the event of a major incident to help CMS prepare for congressional notification.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eBreach Analysis Team (BAT)\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003eOwns the risk decision (low/moderate/high) after IMT conducts a risk assessment.\u003c/li\u003e\u003cli\u003eWorks with the SOP and BO to advise on the Notification and Mitigation Plan.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eLaws and guidance\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eUse this list of applicable laws and guidance to learn more about the processes described in this handbook.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFederal laws\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.congress.gov/113/plaws/publ283/PLAW-113publ283.pdf\"\u003eFederal Information Security Modernization Act\u003c/a\u003e (FISMA) of 2014, Pub. L. 113-283, 128 Stat. 3073 (Dec. 18, 2014) (primarily codified at 44 U.S.C. chapter 35, subchapter 11).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.congress.gov/104/plaws/publ191/PLAW-104publ191.pdf\"\u003eHealth Insurance Portability and Accountability Act\u003c/a\u003e (HIPAA) of 1996, Pub. L. 104-191 (Aug. 21, 1996).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eExecutive orders, memoranda, and directives\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2017/m-17-12_0.pdf\"\u003eOMB Memorandum M-17-12\u003c/a\u003e, Preparing for and Responding to a Breach of Personally Identifiable Information (January 3, 2017).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.whitehouse.gov/wp-content/uploads/2019/11/M-20-04.pdf\"\u003eOMB Memorandum M-20-04\u003c/a\u003e, Fiscal Year 2019-2020 Guidance on Federal Information Security and Privacy Management Requirements (November 19, 2019).\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf\"\u003eOMB Circular A-130, Managing Information as a Strategic Resource\u003c/a\u003e (July 28, 2016).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/the-press-office/2016/07/26/annex-presidential-policy-directive-united-states-cyber-incident\"\u003ePPD-41, Annex for Presidential Policy Directive\u003c/a\u003e – United States Cyber Incident Coordination (July 26, 2016).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/memoranda/2016/m-16-14.pdf\"\u003eOMB Memorandum M-16-14, Category Management Policy 16-2\u003c/a\u003e: Providing Comprehensive Identity Protection Services, Identity Monitoring, and Data Breach Response (July 1, 2016).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS / HHS policy and procedures\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003eCMS Risk Management Handbook (RMH) Chapter 8: Incident Response\u003c/li\u003e\u003cli\u003eCMS Breach Analysis Team Handbook\u003c/li\u003e\u003cli\u003eData Governance Guidelines\u003c/li\u003e\u003cli\u003eHHS PIRT Response Plan Template\u003c/li\u003e\u003cli\u003eCMS Risk Assessment for Breach Notification Determination\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAdditional guidance\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eDepartment of Commerce / National Institute of Standards and Technology (NIST)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eNIST Special Publication 800-34 (Revision 1), \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf\"\u003eContingency Planning Guide for Federal Information Systems and Organizations\u003c/a\u003e (Apr. 2013).\u0026nbsp;\u003c/li\u003e\u003cli\u003eNIST Special Publication 800-61 (Revision 2), \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf\"\u003eComputer Security Incident Handling Guide\u003c/a\u003e (Aug. 2012).\u0026nbsp;\u003c/li\u003e\u003cli\u003eNIST Special Publication 800-122, \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf\"\u003eGuide to Protecting the Confidentiality of PII\u003c/a\u003e (Apr. 2010).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDepartment of Homeland Security (DHS) / United States Computer Emergency Readiness Team (US-CERT)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.cisa.gov/uscert/incident-notification-guidelines\"\u003eUS-CERT Federal Incident Notification Guidelines\u003c/a\u003e\u003c/li\u003e\u003cli\u003eNational Cybersecurity and Communications Integration Center (NCCIC) \u003ca href=\"https://www.cisa.gov/uscert/CISA-National-Cyber-Incident-Scoring-System\"\u003eCyber Incident Scoring System\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eGeneral Services Administration (GSA)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.gsa.gov/buy-through-us/products-services/professional-services/buy-services/identity-protection-services-ips\"\u003eIdentity Protection Services (IPS) Multiple Award Blanket Purchase Agreement (BPA)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"22:T9cb3,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is a POA\u0026amp;M?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Plan of Action and Milestones (POA\u0026amp;M) is a corrective action plan that tracks system weakness and allows System Owners and ISSOs to create a plan to resolve the identified weaknesses over time. A POA\u0026amp;M provides details about the personnel, technology, and funding required to accomplish the elements of the plan, milestones for correcting the weaknesses, and scheduled completion dates for the milestones.\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePOA\u0026amp;M process overview\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe POA\u0026amp;M process begins when a weakness is identified in a CMS FISMA system. Working together, the System/Business Owner and the Authorizing Official (AO) are responsible for mitigating the risk posed by the weakness, with support from the Information System Security Officer (ISSO) and Cyber Risk Advisor (CRA). The steps to the POA\u0026amp;M process are outlined below, and will be described in greater detail throughout the remainder of this guide:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIdentify weaknesses\u003c/li\u003e\u003cli\u003eDevelop a Corrective Action Plan (CAP)\u003c/li\u003e\u003cli\u003eDetermine resource and funding availability\u003c/li\u003e\u003cli\u003eAssign a completion date\u003c/li\u003e\u003cli\u003eExecute the Corrective Action Plan (CAP)\u003c/li\u003e\u003cli\u003eVerify weakness completion\u003c/li\u003e\u003cli\u003eAccept risk when applicable\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eIdentifying weaknesses\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe term “weakness” represents any information security or privacy vulnerability that could be exploited as a result of a specific control deficiency. Weaknesses can compromise a system’s confidentiality, integrity, or availability. All weaknesses that represent risk to the security or privacy of a system must be corrected and the required mitigation efforts captured in a POA\u0026amp;M.\u0026nbsp;For the purpose of this document, the term “weakness” as defined in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53, rev. 5 \u003c/a\u003ewill be synonymous with the terms finding and vulnerability. These terms are defined below:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eFinding\u003c/strong\u003e – During an assessment or audit, the security and privacy controls of a system are tested, or exercised. A system either satisfies the requirements or a control or does not satisfy it.\u0026nbsp; Findings are the result of the assessment or audit. Findings that do not satisfy a control must be addressed with a POA\u0026amp;M.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eVulnerability\u003c/strong\u003e – A vulnerability is a weakness in a system, a system’s security procedures, its internal controls, or its implementation that could be exploited or triggered by a threat source.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFinding weaknesses\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWeaknesses may be found during an internal or external audit, review, or through Continuous Diagnostics and Mitigation (CDM) efforts. There are a number of specific sources that help system teams identify weaknesses:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eHHS OIG Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eGovernment Accountability Office (GAO) Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eChief Financial Officer (CFO) Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eOMB A-123 Internal Control Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eAnnual Assessments\u003c/li\u003e\u003cli\u003eFISMA Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e or Security Control Assessments (SCA)\u0026nbsp;\u003c/li\u003e\u003cli\u003eMedicare Prescription Drug, Improvement, and Modernization Act of 2003 (MMA) Section 912 Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eInternal Revenue Service (IRS) Safeguard Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eDepartment of Homeland Security (DHS) Risk Vulnerability Assessments (RVA)\u0026nbsp;\u003c/li\u003e\u003cli\u003eDHS Cyber Hygiene\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/penetration-testing\"\u003ePenetration Testing\u0026nbsp;\u003c/a\u003e\u003c/li\u003e\u003cli\u003eVulnerability Scanning\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDuring these assessments, reviews, and audits, weaknesses can be found either proactively or reactively.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProactive - \u003c/strong\u003eProactive weakness identification occurs during regular system reviews conducted by CMS.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eReactive - \u003c/strong\u003eReactive weakness determination indicates that the weakness was identified during an audit or external review, like a penetration test.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWeaknesses are always documented by the source that identified them, and it’s important to indicate the identification source as you create your POA\u0026amp;M.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeakness severity levels\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere are three severity levels for all weaknesses discovered during assessments, audits, and tests. The risk the weakness poses to the agency’s overall security and privacy posture determines a weakness’ severity level . There are three levels of severity as defined by OMB: significant deficiency, reportable condition, and weakness.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWeakness severity levels\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eSignificant deficiency\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA weakness is considered a \u003cstrong\u003esignificant deficiency\u003c/strong\u003e if it drastically restricts the capability of the agency to carry out its mission or if it compromises the security or privacy of its information, information systems, personnel, or other resources, operations, or assets.\u0026nbsp;\u003c/p\u003e\u003cp\u003eSenior management must be notified and immediate or near immediate corrective action must be taken.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eReportable Condition\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA \u003cstrong\u003ereportable condition\u003c/strong\u003e is a weakness that affects the efficiency and effectiveness of agency operations.\u0026nbsp;\u003c/p\u003e\u003cp\u003eDue to its lower associated risk, corrective actions for a reportable condition may be scheduled over a longer period of time. The control auditor or assessor will make the determination that a weakness is a reportable condition.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWeakness\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eAll other weaknesses that do not rise to the level of a significant deficiency or reportable condition must be categorized as a weakness.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThey must be mitigated in a timely and efficient manner, as resources permit.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe weakness severity level can be obtained from the source or the audit report. Most findings will generally be categorized as a “weakness”. In the event that a weakness is designated as a “significant deficiency”, then contact the \u003ca href=\"mailto:ciso@cms.hhs.gov\"\u003eCISO mailbox \u003c/a\u003efor further guidance.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeakness risk level\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final\"\u003eNIST SP 800-30 \u003c/a\u003econtains the definitions and the practical guidance necessary for assessing and mitigating identified risks to IT systems. Risk level is dependent on multiple factors, such as \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFederal Information Processing Standard (FIPS) 199 \u003c/a\u003ecategory, operating environment, compensating controls, nature of the vulnerability, and impact if a system is compromised.\u003c/p\u003e\u003cp\u003eRisk can be evaluated either qualitatively or quantitatively and is typically expressed in its simplified form as:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRISK = THREAT x IMPACT x LIKELIHOOD\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe result of the analysis of the risk(s) from following the NIST SP 800-30 guide will recommend the overall risk level assigned to FISMA system of record.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRoot Cause Analysis (RCA)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll weaknesses must be examined to determine their root cause prior to documentation in the\u003c/p\u003e\u003cp\u003ePOA\u0026amp;M. \u003cstrong\u003eRoot Cause Analysis (RCA)\u003c/strong\u003e is an important and effective methodology used to correct information security or privacy weaknesses by eliminating the underlying cause. Various factors are reviewed to determine if they are the underlying cause of the weakness. Proper evaluation ensures the cause, not the symptom, is treated and prevents resources from being expended unnecessarily on addressing the same weakness.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrioritizing weaknesses\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS takes a risk management approach to ensure that critical and high-impact weaknesses\u0026nbsp;\u003c/p\u003e\u003cp\u003etake precedence over lower security weaknesses. The following chart will help CMS System/Business Owners and ISSOs prioritize weaknesses on an ongoing basis to ensure that high-priority weaknesses receive the funding and the resources necessary to remediate or mitigate the most significant risks.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePrioritization factor\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDescription\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk level/severity\u003c/td\u003e\u003ctd\u003e\u003cp\u003eWeaknesses on a High or Moderate system or weaknesses that contribute to a material weakness, significant deficiency or reportable condition will normally require more immediate resolution.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis prioritization factor must consider the following elements:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eSensitivity and criticality of information on the system, such as personally identifiable information (PII).\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe estimated likelihood of the weakness occurring and/or being exploited.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe cost of a potential occurrence or exploitation in terms of dollars, resources,, and/or reputation\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAnalysis\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe weakness must be analyzed to determine if there are any other processes or system relationships that it may affect.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDoes the weakness fall within the system authorization boundary?\u0026nbsp;\u003c/li\u003e\u003cli\u003eIs it a potential program weakness?\u0026nbsp;\u003c/li\u003e\u003cli\u003eIs the weakness a systemic issue (across the enterprise) or is it an isolated event?\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSystemic issues represent much greater risk and may be a higher priority.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSource\u003c/td\u003e\u003ctd\u003eWhat is the source of the weakness? For example, if the weakness resulted from an audit and is considered a significant deficiency, then greater attention should be focused on this weakness.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVisibility\u003c/td\u003e\u003ctd\u003eHas the weakness drawn a high level of visibility external to the system or program? In some cases, a lower level weakness is a higher priority due to visibility. There are times when senior management or outside organizations focus on a specific weakness. Such weaknesses may take priority.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eRegardless of how the weakness is found and how severe it is,\u0026nbsp;it’s critical that system teams work together to create a Corrective Action Plan (CAP) to address it.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDevelop a Corrective Action Plan (CAP)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAfter weaknesses have been identified and the root cause has been determined, a \u003cstrong\u003eCorrective Action Plan (CAP)\u003c/strong\u003e must be developed. The CAP identifies:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe specific tasks, or “milestones”, that need to be accomplished to reduce or eliminate weakness\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe resources required to accomplish the plan\u003c/li\u003e\u003cli\u003eA timeline for correcting the weakness including a completion date\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe milestones in the CAP must provide specific, action-oriented descriptions of the tasks/steps that the stakeholder will take to mitigate the weakness. When creating your milestones, be sure that they are:\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSpecific\u003c/strong\u003e – target a specific area for improvement\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eMeasurable\u003c/strong\u003e – quantify or at least suggest an indicator of progress\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eAssignable\u003c/strong\u003e – specify who will do it\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRealistic\u003c/strong\u003e – state what results can realistically be achieved, given available resources\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eTime-related\u003c/strong\u003e – specify when the result(s) can be achieved.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe number of milestones written per weakness must directly correspond to the number of steps or corrective actions necessary to fully address and resolve the weakness. Each weakness must have at least one corresponding milestone with an estimated completion date and resource requirements to remediate the weakness. The chart below provides samples of compliant and non-compliant milestones that system teams can use when writing their CAP.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eExamples of appropriate milestones\u0026nbsp;\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePOA\u0026amp;M description\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eExample\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eMilestones with completion dates\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP)\u003c/td\u003e\u003ctd\u003eInappropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eEnsure vulnerability scanning covers the entire environment; (11/15/2018)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP)\u003c/td\u003e\u003ctd\u003eAppropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eSchedule a review of the environment inventory; (11/15/2018)\u003c/li\u003e\u003cli\u003eUpdate the SSPP and the vulnerability scanner to reflect the updated inventory; (1/31/2019)\u003c/li\u003e\u003cli\u003eConduct a vulnerability scan to check that the entire inventory is included; (2/15/2019)\u003c/li\u003e\u003cli\u003eImplement an ongoing process to evaluate and update the inventory, the SSPP, and the vulnerability scans on a regular basis; (3/15/2019)\u003c/li\u003e\u003cli\u003ePerform a vulnerability scan and cross check the output with the updated inventory list to verify that the entire environment is included; (4/15/2019)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit logs are not periodically reviewed\u003c/td\u003e\u003ctd\u003eInappropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eEnsure that audit logs are periodically reviewed; (12/15/2018)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit logs are not periodically reviewed\u003c/td\u003e\u003ctd\u003eAppropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eReview policy to ensure that audit log review is required; (12/15/2018)\u003c/li\u003e\u003cli\u003eIdentify the SO; (12/16/2018)\u003c/li\u003e\u003cli\u003eEstablish communication and training to convey the requirement of audit log review; (2/28/2019)\u003c/li\u003e\u003cli\u003eSchedule a follow-up review with the SO to ensure that audit log review is taking place. (3/31/2019)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe CAP should be a collaborative effort with stakeholders including the CISO, System/Business Owners, System Developers and Maintainers, ISSOs, and others as needed. These stakeholders ensure that the CAP is created, executed, monitored, and worked to closure or risk-based acceptance.\u003c/p\u003e\u003cp\u003eOMB provides a standard POA\u0026amp;M format which is utilized at CMS. This structure improves the stakeholders’ ability to easily locate information and organize details for analysis. The CAP format includes a location for the identified program weakness, any associated milestones, and the necessary resources required.\u0026nbsp;\u003c/p\u003e\u003cp\u003eOnce the CAP is documented, the plan must be entered into \u003ca href=\"https://cfacts.cms.gov/\"\u003eCFACTS\u003c/a\u003e in the form of a series of milestone records. The status of the POA\u0026amp;M will automatically be moved from “draft” to “ongoing” 30 days after the weakness creation date. Once a milestone has been accepted/approved and closed, the record must be retained for one year.\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDetermine resource and funding availability\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eMaking funding decisions is often a collaborative exercise that involves multiple system personnel and stakeholders. Examples of questions to ask to determine if your team has the resources to appropriately respond to a weakness are:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eIs one team or person enough or will the participation of a larger team be needed?\u0026nbsp;\u003c/li\u003e\u003cli\u003eCan the task be accomplished within a week or will it take several months?\u0026nbsp;\u003c/li\u003e\u003cli\u003eHow serious is the weakness?\u0026nbsp;\u003c/li\u003e\u003cli\u003eWhat is this weakness’ risk level?\u0026nbsp;\u003c/li\u003e\u003cli\u003eHow complex is the CAP?\u0026nbsp;\u003c/li\u003e\u003cli\u003eDo we need to purchase equipment?\u003c/li\u003e\u003cli\u003eCan the weakness be addressed with existing funding or will we require new allocation from an existing budget source?\u0026nbsp;\u003c/li\u003e\u003cli\u003eWill my addressing this milestone require changes to existing policy or code?\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe System/Business Owner, ISSOs, and other stakeholders must ensure that adequate resources are allocated to mitigate or remediate weaknesses. They must also work together to determine the funding stream required to address the weakness, and any full-time equivalent (FTE) resources required to remediate or mitigate each weakness on the POA\u0026amp;M. The resources required for weakness remediation must fall into one of the following three categories:\u003c/p\u003e\u003col\u003e\u003cli\u003eUsing current resources allocated for the security and/or management of a program or system to complete remediation activities\u003c/li\u003e\u003cli\u003eReallocating existing funds that are appropriated and available for the remediation, or redirecting existing personnel\u003c/li\u003e\u003cli\u003eRequesting additional funding or personnel\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eDuplicate or similar weaknesses shall be documented in one POA\u0026amp;M, existing or new, to avoid inconsistencies. If a related POA\u0026amp;M already exists, the additional weakness shall be noted in the comment field.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAssign a completion date\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSystem/Business Owners, ISSOs, and other stakeholders must determine the scheduled completion date for each weakness using the criteria established by the remediation and mitigation timeline, the risk level, and the severity level. The milestone(s) completion date must not exceed the scheduled completion date assigned to the weakness.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIt is also a good practice to first determine the milestones with completion dates, as this will help determine a more accurate overall scheduled completion date for the weakness. The weakness schedule completion date is a calculated date. It is determined by the identified date and the risk level. The scheduled completion date established at the creation of the weakness must not be modified after the weakness is reported to OMB. POA\u0026amp;Ms become reportable once the status changes from “Draft” to “Ongoing” in CFACTS.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf a weakness is not remediated within the scheduled completion date, a new estimated completion date must be determined and documented in the Changes to Milestones and Comment fields in the POA\u0026amp;M in CFACTS.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNOTE: In use cases where a responsive and timely POA\u0026amp;M cannot be developed, the ISSO can choose to consider the Risk Based Decision (RBD) process to request the Authorizing Official (AO) to consider a risk acceptance until such time the vulnerability can be remediated.\u003c/em\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eExecute the Corrective Action Plan (CAP)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA designated Point of Contact (POC), responsible for ensuring proper execution of the CAP, must be identified for each weakness and its milestones. Individual(s) responsible for the execution of the CAP vary widely depending on the organization, system, milestones, and weakness.\u003c/p\u003e\u003cp\u003eThis POC resource will be key to identifying an “owner” of the milestone and ensuring the milestone is worked to the eventual remediation of the weakness or acceptable mitigation of the weakness. Once the planning of the necessary corrective action is complete and adequate resources have been made available, remediation or mitigation activities will proceed in accordance with the plan.\u003c/p\u003e\u003cp\u003eIf the completion of a milestone extends past its original estimated completion date, an update to the milestone and the completion date of the milestone must be captured in the “Changes to Milestone” field of CFACTS. If the scheduled completion date has passed before the weakness is remediated or mitigated, the weakness must default to “Delayed” status and a justification with a new estimated completion date must be documented in the “Comment” field and the “Changes to Milestone” field of the relevant weakness in CFACTS.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eVerify weakness completion\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS requires that all information in the POA\u0026amp;M be updated at least quarterly, ensuring accuracy for efficient tracking and reporting. As part of the review process, the ISSO will:\u003c/p\u003e\u003cul\u003e\u003cli\u003eValidate that the weakness is properly identified and prioritized\u003c/li\u003e\u003cli\u003eEnsure that appropriate resources have been made available to resolve the weakness\u003c/li\u003e\u003cli\u003eEnsure that the schedule for resolving the weakness is both appropriate and achievable\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eAccept risk when applicable\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA POA\u0026amp;M is a plan to resolve unacceptable risks. In rare cases, the Business Owner can present a case for accepting the risk to the AO or CIO, who may make the decision to accept the risk at their discretion. This is part of the Risk Based Decision (RBD) process. After approval, RBDs shall be reviewed at least annually to ensure the risk remains acceptable and updated as events occur and information changes. RBDs are managed in CFACTS under the \"RBD\" tab.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eClosing a POA\u0026amp;M\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePOA\u0026amp;Ms designated as Low and Moderate are closed by the ISSO and spot audited by a CRA.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms designed as Critical and High are closed by the CRA.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms generated from audits should be reviewed by the auditor prior to closure.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms resulting from a Penetration Test (PenTest) are closed by the PenTest team after the re-test has been performed.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eReports\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eReporting is a critical component of POA\u0026amp;M management, and CMS reports its remediation efforts on a monthly basis. The information in the POA\u0026amp;M must be maintained continuously to communicate overall progress. CMS must submit POA\u0026amp;M updates at least once a month (by the 3rd business day of each month) to HHS to demonstrate the status of POA\u0026amp;M mitigation or remediation activities.\u003c/p\u003e\u003cp\u003eCMS must submit the following information in accordance with the Department POA\u0026amp;M reporting requirements:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAll POA\u0026amp;Ms associated with a program, system and/or component that are within an authorization boundary. POA\u0026amp;Ms must be tied to the individual system and/or component and not the authorization boundary.\u003c/li\u003e\u003cli\u003eAn explanation associated with each delayed POA\u0026amp;M and a revised estimated completion date.\u003c/li\u003e\u003cli\u003eCompleted POA\u0026amp;Ms for up to one year from the date of completion.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eWeakness remediation and mitigation timeline\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAfter positive identification of scan findings or approval of security assessment and/or audit report, all findings/weaknesses shall be documented in a POA\u0026amp;M, reported to HHS, and remediated/mitigated within the following remediation timelines.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eCritical within 15 days\u003c/li\u003e\u003cli\u003e\u0026nbsp;High within 30 days\u003c/li\u003e\u003cli\u003eModerate within 90 days\u003c/li\u003e\u003cli\u003eLow within 365 days\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBusiness Owners, ISSOs, and/or other POA\u0026amp;M stakeholders must work together to determine the scheduled completion date for each POA\u0026amp;M within the specified remediation timelines. These timelines are based on the date the weakness is identified, not the date the POA\u0026amp;M is created. Stakeholders should complete and submit their CAAT templates in a timely manner to allow for the maximum time to complete the remediation/mitigation.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf it is determined that additional time is needed to remediate or mitigate a weakness, the justification with a modified estimated completion date shall be documented in the POA\u0026amp;M in the Changes to Milestones and Comment fields in CFACTS. If weaknesses are not remediated within the scheduled completion date, the status shall change to “Delayed”.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeaknesses discovered during a government audit\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWeaknesses identified during a government audit (i.e., Inspector General or GAO audit) shall be documented in the POA\u0026amp;M after the audit draft report is produced, regardless of CMS acceptance of the identified weakness(es). Disagreements on findings that cannot be resolved between CMS and the auditing office shall be elevated to the Department for resolution. Systems must review and update POA\u0026amp;Ms at least quarterly. In addition, compensating controls must be in place and documented until weaknesses are remediated or mitigated to an acceptable level of risk.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eCFACTS\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eStakeholders must use\u0026nbsp;\u003ca href=\"https://cfacts.cms.gov/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eCFACTS\u003c/a\u003e, the CMS GRC tool, to identify, track, and manage all system weaknesses and associated POA\u0026amp;Ms to closure for CMS information systems. Users who need access to CFACTS may request an account and appropriate privileges through the Enterprise User Administration (EUA). The job code is \u003cstrong\u003eCFACTS_User_P\u003c/strong\u003e. Once the job code is assigned, the user must email the CISO mailbox at \u003ca href=\"mailto:ciso@cms.hhs.gov\"\u003eciso@cms.hhs.gov\u003c/a\u003e to notify the CISO of the user’s role (ISSO, System Developer, or System/Business Owner).\u003c/p\u003e\u003cp\u003eThe \u003cstrong\u003eCFACTS User Manual\u003c/strong\u003e provides detailed instructions for processing POA\u0026amp;M actions in the CFACTS tracking system. The User Manual can be accessed under the \u003cstrong\u003eCFACTS Documents\u003c/strong\u003e section on the \u003cstrong\u003eCFACTS Artifacts\u003c/strong\u003e page which can be accessed by clicking on the CFACTS Artifacts icon on the welcome page.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePOA\u0026amp;M Glossary\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe following glossary will help system teams understand the language of the POA\u0026amp;M process.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eTerm\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDefinition\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAnnual Assessment\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe process of validating the effective implementation of security and privacy controls in the information system and its environment of operation within every three hundred sixty-five (365) days in accordance with the CMS Information Security (IS) Acceptable Risk Safeguards (ARS) Including CMS Minimum Security Requirements (CMSR) Standard, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit\u003c/td\u003e\u003ctd\u003eAn independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCapital Planning and Investment Control\u003c/td\u003e\u003ctd\u003eA decision-making process for ensuring that investments integrate strategic planning, budgeting, procurement, and the management of or in support of Agency missions and business needs. [OMB Circular No. A-11]. The term comes from the Clinger-Cohen Act of 1996; while originally focused on IT, it now applies also to non-IT investments.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCommon Control\u003c/td\u003e\u003ctd\u003eA security or privacy control that is inherited by one or more organizational information systems. See Security Control Inheritance.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompleted\u003c/td\u003e\u003ctd\u003eA status assigned when all corrective actions have been completed or closed for a weakness and the weakness has been verified as successfully mitigated. Documentation is required to demonstrate the weakness has been adequately resolved. When assigning the status of ‘Completed’, the date of completion must also be included.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompletion date\u003c/td\u003e\u003ctd\u003eThe action date when all weaknesses have been fully resolved and the corrective action plan has been tested.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eControl activities\u003c/td\u003e\u003ctd\u003eThe policies and procedures that help ensure that management directives are carried out. They help ensure that necessary actions are taken to address risks to achievement of the entity’s objectives. Control activities, whether automated or manual, help achieve control objectives and are applied at various organizational and functional levels.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eControl deficiency\u003c/td\u003e\u003ctd\u003eA deficiency that exists when the design or operation of a control does not allow management or employees to, in the normal course of performing their assigned functions, prevent or detect breaches of confidentiality, integrity, or availability on a timely basis. (See also design deficiency or operations deficiency)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCorrective Action Plan (CAP)\u003c/td\u003e\u003ctd\u003eThe plan management formulates to document the procedures and milestones identified to correct control deficiencies.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCriteria\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA context for evaluating evidence and understanding the findings, conclusions, and recommendations included in the report. Criteria represent the laws, regulations, contracts, grant agreements, standards, specific requirements, measures, expected performance, defined business practices, and benchmarks against which performance is compared or evaluated.\u003c/p\u003e\u003cp\u003eCriteria identify the required or desired state or expectation with respect to the program or operation.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDelayed\u003c/td\u003e\u003ctd\u003eA status assigned when a weakness continues to be mitigated after the original scheduled completion date has passed. When assigning the status of ‘Delayed,’ an explanation must be provided in the milestone as to why the delay is occurring, as well as the revised completion date.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDesign deficiency\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA deficiency that exists when a control necessary to meet the control objective is missing or an existing control is not properly designed, so that even if the control operates as designed the control objective is not always met.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDraft\u003c/td\u003e\u003ctd\u003eA status that indicates that a weakness requires review and approval prior to “official” entry in the POA\u0026amp;M. Types of review that may take place while a weakness is in draft status would be: reviewing to determine if the weakness already exists and would be a duplicate; reviewing to determine if the organization will accept the risk, or apply for a waiver; etc.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eEvidence\u003c/td\u003e\u003ctd\u003eAny information used by the auditor, tester, or evaluator, to determine whether the information being audited, evaluated, or assessed is stated in accordance with the established criteria.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFISMA Audit\u003c/td\u003e\u003ctd\u003eA FISMA assessment designed to determine areas of compliance and areas requiring remediation to become FISMA compliant.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFederal Information Security Modernization Act (FISMA)\u003c/td\u003e\u003ctd\u003eRequires agencies to integrate information technology (IT) security into their capital planning and enterprise architecture processes at the agency, conduct annual IT security reviews of all programs and systems, and report the results of those reviews to the OMB. [NIST SP 800-65]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFindings\u003c/td\u003e\u003ctd\u003eConclusions based on an evaluation of sufficient, appropriate evidence against criteria.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInformation Security Risk\u003c/td\u003e\u003ctd\u003eThe risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and /or information systems.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePrimary Information System Security Officer (ISSO)\u003c/td\u003e\u003ctd\u003eIndividual with assigned responsibility for maintaining the appropriate operational security and privacy posture for an information system or program.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInitial audit findings\u003c/td\u003e\u003ctd\u003eAny type of audit conducted on a financial system or a non-financial system.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInternal control\u003c/td\u003e\u003ctd\u003eAn integral component of an organization’s management systems that provides reasonable assurance that the following objectives are being achieved: effectiveness and efficiency of operations, reliability of financial reporting, or compliance with applicable laws and regulations.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eManagement controls\u003c/td\u003e\u003ctd\u003eThe security or privacy controls (i.e., safeguards or countermeasures) for an information system that focus on the management of risk and the management of information system security and privacy.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eMaterial weakness\u003c/td\u003e\u003ctd\u003eMaterial weaknesses includes reportable conditions in which the Secretary or Component Head determines to be significant enough to report outside of the Department. Material weakness in internal control over financial reporting is a reportable condition, or combination of reportable conditions, that results in more than a remote likelihood that a material misstatement of the financial statements, or other significant financial reports, will not be prevented or detected.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eMetrics\u0026nbsp;\u003c/td\u003e\u003ctd\u003eTools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance-related data.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eNon-conformance\u0026nbsp;\u003c/td\u003e\u003ctd\u003eInstances in which financial management systems do not substantially conform to financial systems requirements. Financial management systems include both financial and financially-related (or mixed) systems.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOngoing\u003c/td\u003e\u003ctd\u003eA status assigned when a weakness is in the process of being mitigated and has not yet exceeded the original scheduled completion date.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOperational controls\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe security or privacy controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by people (as opposed to systems).\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOperations deficiency\u003c/td\u003e\u003ctd\u003eA deficiency that exists when a properly designed control does not operate as designed or when the person performing the control is not qualified or properly skilled to perform the control effectively.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePending verification\u003c/td\u003e\u003ctd\u003eA status that indicates that all milestones/corrective actions have been completed but require review and sign-off to ensure effective resolution.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePlan of Action and Milestones (POA\u0026amp;M)\u003c/td\u003e\u003ctd\u003eA FISMA mandated corrective action plan to identify and resolve information security and privacy weaknesses. A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePotential impact\u003c/td\u003e\u003ctd\u003eThe loss of confidentiality, integrity, or availability could be expected to have: (i) a limited adverse effect (FIPS 199 low); (ii) a serious adverse effect (FIPS 199 moderate); or (iii) a severe or catastrophic adverse effect (FIPS 199 high) on organizational operations, organizational assets, or individuals.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eProgram\u003c/td\u003e\u003ctd\u003eAn organized set of activities directed toward a goal or particular set of goals or objectives for which the program is accountable; a distinct set of activities and strategies organized toward achieving a specific purpose. A program is a representation of what is delivered to the public. Programs usually operate for indefinite or continuous periods, but may consist of several projects or initiatives.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eReportable condition\u0026nbsp;\u003c/td\u003e\u003ctd\u003eReportable conditions overall include a control deficiency, or combination of control deficiencies, that in management’s judgment, must be communicated because they represent significant weaknesses in the design or operation of an internal control that could adversely affect the organization’s ability to meet its internal control objectives.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eResilience\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs. [NIST SP 800-39, Adapted]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Information system-related security and privacy risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk accepted\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA status assigned when the weakness risk has been accepted. When assigning this status, an acceptance of the risk must be certified by the appropriate Authorizing Official and documented accordingly. The weakness and corresponding risk must be monitored periodically to ensure the associated risk remains at an acceptable level.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSafeguards\u0026nbsp;\u003c/td\u003e\u003ctd\u003eProtective measures prescribed to meet the security and privacy requirements specified for an information system. Safeguards may include security and privacy features, management constraints, personnel security, and security of physical structures, areas, and devices; synonymous with security and privacy controls and countermeasures.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eScheduled or estimated completion date\u003c/td\u003e\u003ctd\u003eA realistic estimate of the amount of time it will take to complete all associated milestones for a POA\u0026amp;M.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecurity Control Assessment (SCA)\u003c/td\u003e\u003ctd\u003eThe testing and/or evaluation of the management, operational, and technical security controls in an information system to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. [NIST SP 800-37]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecurity Control Inheritance\u003c/td\u003e\u003ctd\u003eA situation in which an information system or application receives protection from security and privacy controls (or portions of security and privacy controls) that are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides. See Common Control.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSignificant deficiency\u003c/td\u003e\u003ctd\u003eA weakness in an agency’s overall information systems security and privacy program or management control structure, or within one or more information systems, that significantly restricts the capability of the agency to carry out its mission or compromises the security or privacy of its information, information systems, personnel, or other resources, operations, or assets. In this context, the risk is great enough that the agency head and outside agencies must be notified and immediate or near-immediate corrective action must be taken.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eTechnical controls\u003c/td\u003e\u003ctd\u003eSecurity controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system. [FIPS 200]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eThreat\u003c/td\u003e\u003ctd\u003eAny potential danger to information or systems. A potential threat event, if realized, would cause an undesirable impact. The undesirable impact can come in many forms, but often results in a financial loss. A threat agent could be an intruder accessing the network through a port on the firewall, a process of accessing data in a way that violates that security or privacy policy, a tornado wiping out a facility, or an employee making an unintentional mistake that could expose confidential information or destroy a file’s integrity.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe absence or weakness of a safeguard that could be exploited; the absence or weakness of cumulative controls protecting a particular asset. Vulnerability is a software, hardware, or procedure weakness that may provide an attacker the open door he is looking for to enter a computer or network and have unauthorized access to resources within the environment.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eWaiver\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA status provided when the weakness risk has been accepted and justification has been appropriately documented. Justification of non- compliance must follow the agency's waiver policy and be documented accordingly.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eWeakness\u003c/td\u003e\u003ctd\u003eThe absence of adequate controls.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e"])</script><script>self.__next_f.push([1,"23:T9cb3,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is a POA\u0026amp;M?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Plan of Action and Milestones (POA\u0026amp;M) is a corrective action plan that tracks system weakness and allows System Owners and ISSOs to create a plan to resolve the identified weaknesses over time. A POA\u0026amp;M provides details about the personnel, technology, and funding required to accomplish the elements of the plan, milestones for correcting the weaknesses, and scheduled completion dates for the milestones.\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePOA\u0026amp;M process overview\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe POA\u0026amp;M process begins when a weakness is identified in a CMS FISMA system. Working together, the System/Business Owner and the Authorizing Official (AO) are responsible for mitigating the risk posed by the weakness, with support from the Information System Security Officer (ISSO) and Cyber Risk Advisor (CRA). The steps to the POA\u0026amp;M process are outlined below, and will be described in greater detail throughout the remainder of this guide:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIdentify weaknesses\u003c/li\u003e\u003cli\u003eDevelop a Corrective Action Plan (CAP)\u003c/li\u003e\u003cli\u003eDetermine resource and funding availability\u003c/li\u003e\u003cli\u003eAssign a completion date\u003c/li\u003e\u003cli\u003eExecute the Corrective Action Plan (CAP)\u003c/li\u003e\u003cli\u003eVerify weakness completion\u003c/li\u003e\u003cli\u003eAccept risk when applicable\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eIdentifying weaknesses\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe term “weakness” represents any information security or privacy vulnerability that could be exploited as a result of a specific control deficiency. Weaknesses can compromise a system’s confidentiality, integrity, or availability. All weaknesses that represent risk to the security or privacy of a system must be corrected and the required mitigation efforts captured in a POA\u0026amp;M.\u0026nbsp;For the purpose of this document, the term “weakness” as defined in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53, rev. 5 \u003c/a\u003ewill be synonymous with the terms finding and vulnerability. These terms are defined below:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eFinding\u003c/strong\u003e – During an assessment or audit, the security and privacy controls of a system are tested, or exercised. A system either satisfies the requirements or a control or does not satisfy it.\u0026nbsp; Findings are the result of the assessment or audit. Findings that do not satisfy a control must be addressed with a POA\u0026amp;M.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eVulnerability\u003c/strong\u003e – A vulnerability is a weakness in a system, a system’s security procedures, its internal controls, or its implementation that could be exploited or triggered by a threat source.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFinding weaknesses\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWeaknesses may be found during an internal or external audit, review, or through Continuous Diagnostics and Mitigation (CDM) efforts. There are a number of specific sources that help system teams identify weaknesses:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eHHS OIG Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eGovernment Accountability Office (GAO) Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eChief Financial Officer (CFO) Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eOMB A-123 Internal Control Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eAnnual Assessments\u003c/li\u003e\u003cli\u003eFISMA Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e or Security Control Assessments (SCA)\u0026nbsp;\u003c/li\u003e\u003cli\u003eMedicare Prescription Drug, Improvement, and Modernization Act of 2003 (MMA) Section 912 Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eInternal Revenue Service (IRS) Safeguard Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eDepartment of Homeland Security (DHS) Risk Vulnerability Assessments (RVA)\u0026nbsp;\u003c/li\u003e\u003cli\u003eDHS Cyber Hygiene\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/penetration-testing\"\u003ePenetration Testing\u0026nbsp;\u003c/a\u003e\u003c/li\u003e\u003cli\u003eVulnerability Scanning\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDuring these assessments, reviews, and audits, weaknesses can be found either proactively or reactively.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProactive - \u003c/strong\u003eProactive weakness identification occurs during regular system reviews conducted by CMS.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eReactive - \u003c/strong\u003eReactive weakness determination indicates that the weakness was identified during an audit or external review, like a penetration test.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWeaknesses are always documented by the source that identified them, and it’s important to indicate the identification source as you create your POA\u0026amp;M.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeakness severity levels\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere are three severity levels for all weaknesses discovered during assessments, audits, and tests. The risk the weakness poses to the agency’s overall security and privacy posture determines a weakness’ severity level . There are three levels of severity as defined by OMB: significant deficiency, reportable condition, and weakness.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWeakness severity levels\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eSignificant deficiency\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA weakness is considered a \u003cstrong\u003esignificant deficiency\u003c/strong\u003e if it drastically restricts the capability of the agency to carry out its mission or if it compromises the security or privacy of its information, information systems, personnel, or other resources, operations, or assets.\u0026nbsp;\u003c/p\u003e\u003cp\u003eSenior management must be notified and immediate or near immediate corrective action must be taken.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eReportable Condition\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA \u003cstrong\u003ereportable condition\u003c/strong\u003e is a weakness that affects the efficiency and effectiveness of agency operations.\u0026nbsp;\u003c/p\u003e\u003cp\u003eDue to its lower associated risk, corrective actions for a reportable condition may be scheduled over a longer period of time. The control auditor or assessor will make the determination that a weakness is a reportable condition.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWeakness\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eAll other weaknesses that do not rise to the level of a significant deficiency or reportable condition must be categorized as a weakness.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThey must be mitigated in a timely and efficient manner, as resources permit.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe weakness severity level can be obtained from the source or the audit report. Most findings will generally be categorized as a “weakness”. In the event that a weakness is designated as a “significant deficiency”, then contact the \u003ca href=\"mailto:ciso@cms.hhs.gov\"\u003eCISO mailbox \u003c/a\u003efor further guidance.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeakness risk level\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final\"\u003eNIST SP 800-30 \u003c/a\u003econtains the definitions and the practical guidance necessary for assessing and mitigating identified risks to IT systems. Risk level is dependent on multiple factors, such as \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFederal Information Processing Standard (FIPS) 199 \u003c/a\u003ecategory, operating environment, compensating controls, nature of the vulnerability, and impact if a system is compromised.\u003c/p\u003e\u003cp\u003eRisk can be evaluated either qualitatively or quantitatively and is typically expressed in its simplified form as:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRISK = THREAT x IMPACT x LIKELIHOOD\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe result of the analysis of the risk(s) from following the NIST SP 800-30 guide will recommend the overall risk level assigned to FISMA system of record.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRoot Cause Analysis (RCA)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll weaknesses must be examined to determine their root cause prior to documentation in the\u003c/p\u003e\u003cp\u003ePOA\u0026amp;M. \u003cstrong\u003eRoot Cause Analysis (RCA)\u003c/strong\u003e is an important and effective methodology used to correct information security or privacy weaknesses by eliminating the underlying cause. Various factors are reviewed to determine if they are the underlying cause of the weakness. Proper evaluation ensures the cause, not the symptom, is treated and prevents resources from being expended unnecessarily on addressing the same weakness.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrioritizing weaknesses\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS takes a risk management approach to ensure that critical and high-impact weaknesses\u0026nbsp;\u003c/p\u003e\u003cp\u003etake precedence over lower security weaknesses. The following chart will help CMS System/Business Owners and ISSOs prioritize weaknesses on an ongoing basis to ensure that high-priority weaknesses receive the funding and the resources necessary to remediate or mitigate the most significant risks.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePrioritization factor\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDescription\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk level/severity\u003c/td\u003e\u003ctd\u003e\u003cp\u003eWeaknesses on a High or Moderate system or weaknesses that contribute to a material weakness, significant deficiency or reportable condition will normally require more immediate resolution.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis prioritization factor must consider the following elements:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eSensitivity and criticality of information on the system, such as personally identifiable information (PII).\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe estimated likelihood of the weakness occurring and/or being exploited.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe cost of a potential occurrence or exploitation in terms of dollars, resources,, and/or reputation\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAnalysis\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe weakness must be analyzed to determine if there are any other processes or system relationships that it may affect.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDoes the weakness fall within the system authorization boundary?\u0026nbsp;\u003c/li\u003e\u003cli\u003eIs it a potential program weakness?\u0026nbsp;\u003c/li\u003e\u003cli\u003eIs the weakness a systemic issue (across the enterprise) or is it an isolated event?\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSystemic issues represent much greater risk and may be a higher priority.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSource\u003c/td\u003e\u003ctd\u003eWhat is the source of the weakness? For example, if the weakness resulted from an audit and is considered a significant deficiency, then greater attention should be focused on this weakness.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVisibility\u003c/td\u003e\u003ctd\u003eHas the weakness drawn a high level of visibility external to the system or program? In some cases, a lower level weakness is a higher priority due to visibility. There are times when senior management or outside organizations focus on a specific weakness. Such weaknesses may take priority.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eRegardless of how the weakness is found and how severe it is,\u0026nbsp;it’s critical that system teams work together to create a Corrective Action Plan (CAP) to address it.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDevelop a Corrective Action Plan (CAP)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAfter weaknesses have been identified and the root cause has been determined, a \u003cstrong\u003eCorrective Action Plan (CAP)\u003c/strong\u003e must be developed. The CAP identifies:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe specific tasks, or “milestones”, that need to be accomplished to reduce or eliminate weakness\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe resources required to accomplish the plan\u003c/li\u003e\u003cli\u003eA timeline for correcting the weakness including a completion date\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe milestones in the CAP must provide specific, action-oriented descriptions of the tasks/steps that the stakeholder will take to mitigate the weakness. When creating your milestones, be sure that they are:\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSpecific\u003c/strong\u003e – target a specific area for improvement\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eMeasurable\u003c/strong\u003e – quantify or at least suggest an indicator of progress\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eAssignable\u003c/strong\u003e – specify who will do it\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRealistic\u003c/strong\u003e – state what results can realistically be achieved, given available resources\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eTime-related\u003c/strong\u003e – specify when the result(s) can be achieved.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe number of milestones written per weakness must directly correspond to the number of steps or corrective actions necessary to fully address and resolve the weakness. Each weakness must have at least one corresponding milestone with an estimated completion date and resource requirements to remediate the weakness. The chart below provides samples of compliant and non-compliant milestones that system teams can use when writing their CAP.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eExamples of appropriate milestones\u0026nbsp;\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePOA\u0026amp;M description\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eExample\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eMilestones with completion dates\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP)\u003c/td\u003e\u003ctd\u003eInappropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eEnsure vulnerability scanning covers the entire environment; (11/15/2018)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP)\u003c/td\u003e\u003ctd\u003eAppropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eSchedule a review of the environment inventory; (11/15/2018)\u003c/li\u003e\u003cli\u003eUpdate the SSPP and the vulnerability scanner to reflect the updated inventory; (1/31/2019)\u003c/li\u003e\u003cli\u003eConduct a vulnerability scan to check that the entire inventory is included; (2/15/2019)\u003c/li\u003e\u003cli\u003eImplement an ongoing process to evaluate and update the inventory, the SSPP, and the vulnerability scans on a regular basis; (3/15/2019)\u003c/li\u003e\u003cli\u003ePerform a vulnerability scan and cross check the output with the updated inventory list to verify that the entire environment is included; (4/15/2019)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit logs are not periodically reviewed\u003c/td\u003e\u003ctd\u003eInappropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eEnsure that audit logs are periodically reviewed; (12/15/2018)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit logs are not periodically reviewed\u003c/td\u003e\u003ctd\u003eAppropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eReview policy to ensure that audit log review is required; (12/15/2018)\u003c/li\u003e\u003cli\u003eIdentify the SO; (12/16/2018)\u003c/li\u003e\u003cli\u003eEstablish communication and training to convey the requirement of audit log review; (2/28/2019)\u003c/li\u003e\u003cli\u003eSchedule a follow-up review with the SO to ensure that audit log review is taking place. (3/31/2019)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe CAP should be a collaborative effort with stakeholders including the CISO, System/Business Owners, System Developers and Maintainers, ISSOs, and others as needed. These stakeholders ensure that the CAP is created, executed, monitored, and worked to closure or risk-based acceptance.\u003c/p\u003e\u003cp\u003eOMB provides a standard POA\u0026amp;M format which is utilized at CMS. This structure improves the stakeholders’ ability to easily locate information and organize details for analysis. The CAP format includes a location for the identified program weakness, any associated milestones, and the necessary resources required.\u0026nbsp;\u003c/p\u003e\u003cp\u003eOnce the CAP is documented, the plan must be entered into \u003ca href=\"https://cfacts.cms.gov/\"\u003eCFACTS\u003c/a\u003e in the form of a series of milestone records. The status of the POA\u0026amp;M will automatically be moved from “draft” to “ongoing” 30 days after the weakness creation date. Once a milestone has been accepted/approved and closed, the record must be retained for one year.\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDetermine resource and funding availability\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eMaking funding decisions is often a collaborative exercise that involves multiple system personnel and stakeholders. Examples of questions to ask to determine if your team has the resources to appropriately respond to a weakness are:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eIs one team or person enough or will the participation of a larger team be needed?\u0026nbsp;\u003c/li\u003e\u003cli\u003eCan the task be accomplished within a week or will it take several months?\u0026nbsp;\u003c/li\u003e\u003cli\u003eHow serious is the weakness?\u0026nbsp;\u003c/li\u003e\u003cli\u003eWhat is this weakness’ risk level?\u0026nbsp;\u003c/li\u003e\u003cli\u003eHow complex is the CAP?\u0026nbsp;\u003c/li\u003e\u003cli\u003eDo we need to purchase equipment?\u003c/li\u003e\u003cli\u003eCan the weakness be addressed with existing funding or will we require new allocation from an existing budget source?\u0026nbsp;\u003c/li\u003e\u003cli\u003eWill my addressing this milestone require changes to existing policy or code?\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe System/Business Owner, ISSOs, and other stakeholders must ensure that adequate resources are allocated to mitigate or remediate weaknesses. They must also work together to determine the funding stream required to address the weakness, and any full-time equivalent (FTE) resources required to remediate or mitigate each weakness on the POA\u0026amp;M. The resources required for weakness remediation must fall into one of the following three categories:\u003c/p\u003e\u003col\u003e\u003cli\u003eUsing current resources allocated for the security and/or management of a program or system to complete remediation activities\u003c/li\u003e\u003cli\u003eReallocating existing funds that are appropriated and available for the remediation, or redirecting existing personnel\u003c/li\u003e\u003cli\u003eRequesting additional funding or personnel\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eDuplicate or similar weaknesses shall be documented in one POA\u0026amp;M, existing or new, to avoid inconsistencies. If a related POA\u0026amp;M already exists, the additional weakness shall be noted in the comment field.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAssign a completion date\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSystem/Business Owners, ISSOs, and other stakeholders must determine the scheduled completion date for each weakness using the criteria established by the remediation and mitigation timeline, the risk level, and the severity level. The milestone(s) completion date must not exceed the scheduled completion date assigned to the weakness.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIt is also a good practice to first determine the milestones with completion dates, as this will help determine a more accurate overall scheduled completion date for the weakness. The weakness schedule completion date is a calculated date. It is determined by the identified date and the risk level. The scheduled completion date established at the creation of the weakness must not be modified after the weakness is reported to OMB. POA\u0026amp;Ms become reportable once the status changes from “Draft” to “Ongoing” in CFACTS.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf a weakness is not remediated within the scheduled completion date, a new estimated completion date must be determined and documented in the Changes to Milestones and Comment fields in the POA\u0026amp;M in CFACTS.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNOTE: In use cases where a responsive and timely POA\u0026amp;M cannot be developed, the ISSO can choose to consider the Risk Based Decision (RBD) process to request the Authorizing Official (AO) to consider a risk acceptance until such time the vulnerability can be remediated.\u003c/em\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eExecute the Corrective Action Plan (CAP)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA designated Point of Contact (POC), responsible for ensuring proper execution of the CAP, must be identified for each weakness and its milestones. Individual(s) responsible for the execution of the CAP vary widely depending on the organization, system, milestones, and weakness.\u003c/p\u003e\u003cp\u003eThis POC resource will be key to identifying an “owner” of the milestone and ensuring the milestone is worked to the eventual remediation of the weakness or acceptable mitigation of the weakness. Once the planning of the necessary corrective action is complete and adequate resources have been made available, remediation or mitigation activities will proceed in accordance with the plan.\u003c/p\u003e\u003cp\u003eIf the completion of a milestone extends past its original estimated completion date, an update to the milestone and the completion date of the milestone must be captured in the “Changes to Milestone” field of CFACTS. If the scheduled completion date has passed before the weakness is remediated or mitigated, the weakness must default to “Delayed” status and a justification with a new estimated completion date must be documented in the “Comment” field and the “Changes to Milestone” field of the relevant weakness in CFACTS.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eVerify weakness completion\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS requires that all information in the POA\u0026amp;M be updated at least quarterly, ensuring accuracy for efficient tracking and reporting. As part of the review process, the ISSO will:\u003c/p\u003e\u003cul\u003e\u003cli\u003eValidate that the weakness is properly identified and prioritized\u003c/li\u003e\u003cli\u003eEnsure that appropriate resources have been made available to resolve the weakness\u003c/li\u003e\u003cli\u003eEnsure that the schedule for resolving the weakness is both appropriate and achievable\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eAccept risk when applicable\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA POA\u0026amp;M is a plan to resolve unacceptable risks. In rare cases, the Business Owner can present a case for accepting the risk to the AO or CIO, who may make the decision to accept the risk at their discretion. This is part of the Risk Based Decision (RBD) process. After approval, RBDs shall be reviewed at least annually to ensure the risk remains acceptable and updated as events occur and information changes. RBDs are managed in CFACTS under the \"RBD\" tab.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eClosing a POA\u0026amp;M\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePOA\u0026amp;Ms designated as Low and Moderate are closed by the ISSO and spot audited by a CRA.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms designed as Critical and High are closed by the CRA.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms generated from audits should be reviewed by the auditor prior to closure.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms resulting from a Penetration Test (PenTest) are closed by the PenTest team after the re-test has been performed.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eReports\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eReporting is a critical component of POA\u0026amp;M management, and CMS reports its remediation efforts on a monthly basis. The information in the POA\u0026amp;M must be maintained continuously to communicate overall progress. CMS must submit POA\u0026amp;M updates at least once a month (by the 3rd business day of each month) to HHS to demonstrate the status of POA\u0026amp;M mitigation or remediation activities.\u003c/p\u003e\u003cp\u003eCMS must submit the following information in accordance with the Department POA\u0026amp;M reporting requirements:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAll POA\u0026amp;Ms associated with a program, system and/or component that are within an authorization boundary. POA\u0026amp;Ms must be tied to the individual system and/or component and not the authorization boundary.\u003c/li\u003e\u003cli\u003eAn explanation associated with each delayed POA\u0026amp;M and a revised estimated completion date.\u003c/li\u003e\u003cli\u003eCompleted POA\u0026amp;Ms for up to one year from the date of completion.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eWeakness remediation and mitigation timeline\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAfter positive identification of scan findings or approval of security assessment and/or audit report, all findings/weaknesses shall be documented in a POA\u0026amp;M, reported to HHS, and remediated/mitigated within the following remediation timelines.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eCritical within 15 days\u003c/li\u003e\u003cli\u003e\u0026nbsp;High within 30 days\u003c/li\u003e\u003cli\u003eModerate within 90 days\u003c/li\u003e\u003cli\u003eLow within 365 days\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBusiness Owners, ISSOs, and/or other POA\u0026amp;M stakeholders must work together to determine the scheduled completion date for each POA\u0026amp;M within the specified remediation timelines. These timelines are based on the date the weakness is identified, not the date the POA\u0026amp;M is created. Stakeholders should complete and submit their CAAT templates in a timely manner to allow for the maximum time to complete the remediation/mitigation.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf it is determined that additional time is needed to remediate or mitigate a weakness, the justification with a modified estimated completion date shall be documented in the POA\u0026amp;M in the Changes to Milestones and Comment fields in CFACTS. If weaknesses are not remediated within the scheduled completion date, the status shall change to “Delayed”.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeaknesses discovered during a government audit\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWeaknesses identified during a government audit (i.e., Inspector General or GAO audit) shall be documented in the POA\u0026amp;M after the audit draft report is produced, regardless of CMS acceptance of the identified weakness(es). Disagreements on findings that cannot be resolved between CMS and the auditing office shall be elevated to the Department for resolution. Systems must review and update POA\u0026amp;Ms at least quarterly. In addition, compensating controls must be in place and documented until weaknesses are remediated or mitigated to an acceptable level of risk.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eCFACTS\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eStakeholders must use\u0026nbsp;\u003ca href=\"https://cfacts.cms.gov/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eCFACTS\u003c/a\u003e, the CMS GRC tool, to identify, track, and manage all system weaknesses and associated POA\u0026amp;Ms to closure for CMS information systems. Users who need access to CFACTS may request an account and appropriate privileges through the Enterprise User Administration (EUA). The job code is \u003cstrong\u003eCFACTS_User_P\u003c/strong\u003e. Once the job code is assigned, the user must email the CISO mailbox at \u003ca href=\"mailto:ciso@cms.hhs.gov\"\u003eciso@cms.hhs.gov\u003c/a\u003e to notify the CISO of the user’s role (ISSO, System Developer, or System/Business Owner).\u003c/p\u003e\u003cp\u003eThe \u003cstrong\u003eCFACTS User Manual\u003c/strong\u003e provides detailed instructions for processing POA\u0026amp;M actions in the CFACTS tracking system. The User Manual can be accessed under the \u003cstrong\u003eCFACTS Documents\u003c/strong\u003e section on the \u003cstrong\u003eCFACTS Artifacts\u003c/strong\u003e page which can be accessed by clicking on the CFACTS Artifacts icon on the welcome page.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePOA\u0026amp;M Glossary\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe following glossary will help system teams understand the language of the POA\u0026amp;M process.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eTerm\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDefinition\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAnnual Assessment\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe process of validating the effective implementation of security and privacy controls in the information system and its environment of operation within every three hundred sixty-five (365) days in accordance with the CMS Information Security (IS) Acceptable Risk Safeguards (ARS) Including CMS Minimum Security Requirements (CMSR) Standard, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit\u003c/td\u003e\u003ctd\u003eAn independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCapital Planning and Investment Control\u003c/td\u003e\u003ctd\u003eA decision-making process for ensuring that investments integrate strategic planning, budgeting, procurement, and the management of or in support of Agency missions and business needs. [OMB Circular No. A-11]. The term comes from the Clinger-Cohen Act of 1996; while originally focused on IT, it now applies also to non-IT investments.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCommon Control\u003c/td\u003e\u003ctd\u003eA security or privacy control that is inherited by one or more organizational information systems. See Security Control Inheritance.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompleted\u003c/td\u003e\u003ctd\u003eA status assigned when all corrective actions have been completed or closed for a weakness and the weakness has been verified as successfully mitigated. Documentation is required to demonstrate the weakness has been adequately resolved. When assigning the status of ‘Completed’, the date of completion must also be included.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompletion date\u003c/td\u003e\u003ctd\u003eThe action date when all weaknesses have been fully resolved and the corrective action plan has been tested.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eControl activities\u003c/td\u003e\u003ctd\u003eThe policies and procedures that help ensure that management directives are carried out. They help ensure that necessary actions are taken to address risks to achievement of the entity’s objectives. Control activities, whether automated or manual, help achieve control objectives and are applied at various organizational and functional levels.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eControl deficiency\u003c/td\u003e\u003ctd\u003eA deficiency that exists when the design or operation of a control does not allow management or employees to, in the normal course of performing their assigned functions, prevent or detect breaches of confidentiality, integrity, or availability on a timely basis. (See also design deficiency or operations deficiency)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCorrective Action Plan (CAP)\u003c/td\u003e\u003ctd\u003eThe plan management formulates to document the procedures and milestones identified to correct control deficiencies.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCriteria\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA context for evaluating evidence and understanding the findings, conclusions, and recommendations included in the report. Criteria represent the laws, regulations, contracts, grant agreements, standards, specific requirements, measures, expected performance, defined business practices, and benchmarks against which performance is compared or evaluated.\u003c/p\u003e\u003cp\u003eCriteria identify the required or desired state or expectation with respect to the program or operation.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDelayed\u003c/td\u003e\u003ctd\u003eA status assigned when a weakness continues to be mitigated after the original scheduled completion date has passed. When assigning the status of ‘Delayed,’ an explanation must be provided in the milestone as to why the delay is occurring, as well as the revised completion date.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDesign deficiency\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA deficiency that exists when a control necessary to meet the control objective is missing or an existing control is not properly designed, so that even if the control operates as designed the control objective is not always met.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDraft\u003c/td\u003e\u003ctd\u003eA status that indicates that a weakness requires review and approval prior to “official” entry in the POA\u0026amp;M. Types of review that may take place while a weakness is in draft status would be: reviewing to determine if the weakness already exists and would be a duplicate; reviewing to determine if the organization will accept the risk, or apply for a waiver; etc.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eEvidence\u003c/td\u003e\u003ctd\u003eAny information used by the auditor, tester, or evaluator, to determine whether the information being audited, evaluated, or assessed is stated in accordance with the established criteria.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFISMA Audit\u003c/td\u003e\u003ctd\u003eA FISMA assessment designed to determine areas of compliance and areas requiring remediation to become FISMA compliant.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFederal Information Security Modernization Act (FISMA)\u003c/td\u003e\u003ctd\u003eRequires agencies to integrate information technology (IT) security into their capital planning and enterprise architecture processes at the agency, conduct annual IT security reviews of all programs and systems, and report the results of those reviews to the OMB. [NIST SP 800-65]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFindings\u003c/td\u003e\u003ctd\u003eConclusions based on an evaluation of sufficient, appropriate evidence against criteria.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInformation Security Risk\u003c/td\u003e\u003ctd\u003eThe risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and /or information systems.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePrimary Information System Security Officer (ISSO)\u003c/td\u003e\u003ctd\u003eIndividual with assigned responsibility for maintaining the appropriate operational security and privacy posture for an information system or program.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInitial audit findings\u003c/td\u003e\u003ctd\u003eAny type of audit conducted on a financial system or a non-financial system.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInternal control\u003c/td\u003e\u003ctd\u003eAn integral component of an organization’s management systems that provides reasonable assurance that the following objectives are being achieved: effectiveness and efficiency of operations, reliability of financial reporting, or compliance with applicable laws and regulations.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eManagement controls\u003c/td\u003e\u003ctd\u003eThe security or privacy controls (i.e., safeguards or countermeasures) for an information system that focus on the management of risk and the management of information system security and privacy.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eMaterial weakness\u003c/td\u003e\u003ctd\u003eMaterial weaknesses includes reportable conditions in which the Secretary or Component Head determines to be significant enough to report outside of the Department. Material weakness in internal control over financial reporting is a reportable condition, or combination of reportable conditions, that results in more than a remote likelihood that a material misstatement of the financial statements, or other significant financial reports, will not be prevented or detected.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eMetrics\u0026nbsp;\u003c/td\u003e\u003ctd\u003eTools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance-related data.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eNon-conformance\u0026nbsp;\u003c/td\u003e\u003ctd\u003eInstances in which financial management systems do not substantially conform to financial systems requirements. Financial management systems include both financial and financially-related (or mixed) systems.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOngoing\u003c/td\u003e\u003ctd\u003eA status assigned when a weakness is in the process of being mitigated and has not yet exceeded the original scheduled completion date.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOperational controls\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe security or privacy controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by people (as opposed to systems).\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOperations deficiency\u003c/td\u003e\u003ctd\u003eA deficiency that exists when a properly designed control does not operate as designed or when the person performing the control is not qualified or properly skilled to perform the control effectively.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePending verification\u003c/td\u003e\u003ctd\u003eA status that indicates that all milestones/corrective actions have been completed but require review and sign-off to ensure effective resolution.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePlan of Action and Milestones (POA\u0026amp;M)\u003c/td\u003e\u003ctd\u003eA FISMA mandated corrective action plan to identify and resolve information security and privacy weaknesses. A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePotential impact\u003c/td\u003e\u003ctd\u003eThe loss of confidentiality, integrity, or availability could be expected to have: (i) a limited adverse effect (FIPS 199 low); (ii) a serious adverse effect (FIPS 199 moderate); or (iii) a severe or catastrophic adverse effect (FIPS 199 high) on organizational operations, organizational assets, or individuals.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eProgram\u003c/td\u003e\u003ctd\u003eAn organized set of activities directed toward a goal or particular set of goals or objectives for which the program is accountable; a distinct set of activities and strategies organized toward achieving a specific purpose. A program is a representation of what is delivered to the public. Programs usually operate for indefinite or continuous periods, but may consist of several projects or initiatives.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eReportable condition\u0026nbsp;\u003c/td\u003e\u003ctd\u003eReportable conditions overall include a control deficiency, or combination of control deficiencies, that in management’s judgment, must be communicated because they represent significant weaknesses in the design or operation of an internal control that could adversely affect the organization’s ability to meet its internal control objectives.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eResilience\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs. [NIST SP 800-39, Adapted]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Information system-related security and privacy risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk accepted\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA status assigned when the weakness risk has been accepted. When assigning this status, an acceptance of the risk must be certified by the appropriate Authorizing Official and documented accordingly. The weakness and corresponding risk must be monitored periodically to ensure the associated risk remains at an acceptable level.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSafeguards\u0026nbsp;\u003c/td\u003e\u003ctd\u003eProtective measures prescribed to meet the security and privacy requirements specified for an information system. Safeguards may include security and privacy features, management constraints, personnel security, and security of physical structures, areas, and devices; synonymous with security and privacy controls and countermeasures.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eScheduled or estimated completion date\u003c/td\u003e\u003ctd\u003eA realistic estimate of the amount of time it will take to complete all associated milestones for a POA\u0026amp;M.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecurity Control Assessment (SCA)\u003c/td\u003e\u003ctd\u003eThe testing and/or evaluation of the management, operational, and technical security controls in an information system to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. [NIST SP 800-37]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecurity Control Inheritance\u003c/td\u003e\u003ctd\u003eA situation in which an information system or application receives protection from security and privacy controls (or portions of security and privacy controls) that are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides. See Common Control.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSignificant deficiency\u003c/td\u003e\u003ctd\u003eA weakness in an agency’s overall information systems security and privacy program or management control structure, or within one or more information systems, that significantly restricts the capability of the agency to carry out its mission or compromises the security or privacy of its information, information systems, personnel, or other resources, operations, or assets. In this context, the risk is great enough that the agency head and outside agencies must be notified and immediate or near-immediate corrective action must be taken.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eTechnical controls\u003c/td\u003e\u003ctd\u003eSecurity controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system. [FIPS 200]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eThreat\u003c/td\u003e\u003ctd\u003eAny potential danger to information or systems. A potential threat event, if realized, would cause an undesirable impact. The undesirable impact can come in many forms, but often results in a financial loss. A threat agent could be an intruder accessing the network through a port on the firewall, a process of accessing data in a way that violates that security or privacy policy, a tornado wiping out a facility, or an employee making an unintentional mistake that could expose confidential information or destroy a file’s integrity.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe absence or weakness of a safeguard that could be exploited; the absence or weakness of cumulative controls protecting a particular asset. Vulnerability is a software, hardware, or procedure weakness that may provide an attacker the open door he is looking for to enter a computer or network and have unauthorized access to resources within the environment.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eWaiver\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA status provided when the weakness risk has been accepted and justification has been appropriately documented. Justification of non- compliance must follow the agency's waiver policy and be documented accordingly.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eWeakness\u003c/td\u003e\u003ctd\u003eThe absence of adequate controls.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e"])</script><script>self.__next_f.push([1,"24:Tb185,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eBackground\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook aligns with the \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNational Institute of Standards and Technology (NIST) Special Publication (SP) 800-57\u003c/a\u003e series, the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS IS2P2\u003c/a\u003e, and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS Acceptable Risk Safeguards (ARS)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://security.cms.gov/learn/federal-information-systems-management-act-fisma\"\u003eFISMA\u003c/a\u003e further emphasizes the importance of continuously monitoring information system security by requiring agencies to conduct assessments of security controls at a risk-defined frequency. The CMS ARS states that CMS information systems must define, develop, disseminate, review, and update its Risk Assessment documentation at least once every three years or whenever a significant change has occurred. This includes a formal, documented system security/privacy package that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and formal, documented processes and procedures to facilitate the implementation of the policy and associated controls.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePolicy\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePolicy delineates the security management structure, clearly assigns security responsibilities, and lays the foundation necessary to reliably measure progress, compliance, and direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems or systems maintained on behalf of CMS to assure the confidentiality, integrity, and availability of CMS information and information systems.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eInformation Systems Security and Privacy Policy (IS2P2)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS IS2P2\u003c/a\u003e defines the framework and policy under which CMS protects and controls access to CMS information and information systems in compliance with the Department of Human and Health Services (HHS) policy, federal law, and regulations. This policy requires all CMS stakeholders to implement adequate information security and privacy safeguards to protect all CMS's sensitive information.\u003c/p\u003e\u003cp\u003eThe policies contained within the CMS IS2P2 assist in satisfying the requirements for controls that require CMS to create a policy and associated procedures related to information systems.\u003c/p\u003e\u003cp\u003eThe dynamic nature of information security and privacy disciplines and the constant need for assessing risk across the CMS environment can result in gaps in policy, outside of the routine policy review cycle. The CMS Policy Framework includes the option to issue a \u003ca href=\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/Policies\"\u003eCIO Directive\u003c/a\u003e to address these types of gaps in CMS policy by providing guidance to CMS stakeholders while a policy is being developed, updated, cleared, and approved.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eChief Information Officer (CIO) Directives\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CMS Chief Information Officer (CIO), the CMS Chief Information Security Officer (CISO), and the CMS Senior Official for Privacy (SOP) jointly develop and maintain the CMS IS2P2. The CIO delegates authority and responsibility to specific organizations and officials within CMS to develop and administer defined aspects of the CMS Information Security and Privacy Program as appropriate.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eStandards\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eStandards define both functional and assurance requirements within the CMS security and privacy environment. CMS policy is executed with the requirements prescribed in standards with the objective of enabling consistency across the CMS environment. The CMS environment includes users, networks, devices, all software, processes, information in storage or transit, applications, services, and systems that can be connected directly or indirectly to networks. These components are responsible for meeting and complying with the security and privacy baseline defined in policy and further prescribed in standards. The parameters and thresholds for policy implementation are built into the CMS standards, and provide a foundation for the procedural guidance provided by the Program Guide series.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eSecrets Management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eA secret is a digital authentication credential. Secrets are individually named sets of sensitive information, and address a broad spectrum of secure data. Secrets need to be protected against unauthorized disclosure, and all keys need to be protected against modification, tempering, deletion and disclosure. There are different types of secrets, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUser passwords\u003c/li\u003e\u003cli\u003eRoot passwords\u003c/li\u003e\u003cli\u003eApplication and database passwords\u003c/li\u003e\u003cli\u003eAuto-generated encryption keys\u003c/li\u003e\u003cli\u003ePrivate encryption keys\u003c/li\u003e\u003cli\u003eApplication Programming Interface (API) keys\u003c/li\u003e\u003cli\u003eApplication keys\u003c/li\u003e\u003cli\u003eSecure Shell (SSH) keys\u003c/li\u003e\u003cli\u003eIAM secret keys\u003c/li\u003e\u003cli\u003eProgrammatic access keys (project / client IDs)\u003c/li\u003e\u003cli\u003eAuthorization tokens\u003c/li\u003e\u003cli\u003eBearer tokens\u003c/li\u003e\u003cli\u003eCertificates\u003c/li\u003e\u003cli\u003ePrivate certificates (e.g. Transport Layer Security (TLS), Secure Sockets Layer (SSL))\u003c/li\u003e\u003cli\u003eRSA and other one-time password devices\u003c/li\u003e\u003cli\u003eAccount tags\u003c/li\u003e\u003cli\u003ePassphrases\u003c/li\u003e\u003cli\u003eAny other application tokens that are deemed confidential\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSecrets management refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.\u003c/p\u003e\u003cp\u003ePasswords and keys are some of the most broadly used and important tools your organization has for authenticating applications and users and providing them with access to sensitive systems, services, and information. Because secrets have to be transmitted securely, secrets management must account for and mitigate the risks to these secrets, both in transit and at rest.\u003c/p\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eNote – \u003c/strong\u003eRoot access keys should be protected at all costs and deleted if possible. A bad actor may shut down servers, delete data, create and destroy users, or any other API capability with the root user’s key. For this reason, CMS highly recommends that root access key should not be in use or should be disabled if already in use. CMS also recommends keeping the root user’s credentials safe and private. Do not share them with other employees or contractors. It is also advisable to activate Multi Factor Authentication (MFA) for the root account to protect it even if the password leaks. Also, access and secret access keys should only be developed at a user level, and never at a root level.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThe security objectives (Confidentiality, Integrity and Availability) should always be protected in regards to secrets management. The \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFederal Information Processing Standards (FIPS) Publication 199\u003c/a\u003e defines three levels of potential impact on organizations or individuals (low, moderate, high) should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability) and has additional examples on the impact of loss of one or more of the security objectives.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eKey Management\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eKey management refers to managing cryptographic keys within a cryptosystem. The term “cryptosystem” is shorthand for “cryptographic system” and refers to a computer system that employs cryptography, a method of protecting information and communications through the use of codes so that only those for whom the information is intended can read and process it.\u003c/p\u003e\u003cp\u003eCryptosystems deal with generating, exchanging, storing, using and replacing keys as needed at the user level.\u003c/p\u003e\u003cp\u003eThe security of the cryptosystem is dependent upon successful key management. Proper management ensures a key stays safe throughout its lifecycle, from generation and use to storing and deletion.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCryptographic Keys\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography.\u003c/p\u003e\u003cp\u003eWith effective cryptographic key management, data that is encrypted can still be protected even in the event of a breach, since encrypted data cannot be decrypted without the right keys. Proper usage of encryption and key management will assist an organization’s efforts to protect their data. \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendations for Key Management (Part 1, Revision 5) \u003c/em\u003e\u003c/a\u003eprovides an updated guideline for general cryptographic key management.\u003c/p\u003e\u003cp\u003eAt CMS, mechanisms are employed to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eProhibit the use of encryption keys that are not recoverable by authorized personnel\u003c/li\u003e\u003cli\u003eRequire senior management approval to authorize recovery of keys by someone other than the key owner\u003c/li\u003e\u003cli\u003eComply with approved cryptography standards mentioned in transit and at rest, as defined in the HHS Standard for Encryption of Computing Devices and Information, and in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAt CMS, cryptographic protection applies to both portable storage devices (e.g., USB memory sticks, CDs, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers). This applies to all digital assets like application software, Data Stores (Such as databases and file systems), Cloud Service, and Software As a Service.\u003c/p\u003e\u003cp\u003eWhen cryptographic mechanisms are needed, CMS information systems use encryption products that have been validated under the Cryptographic Module Validation Program to confirm compliance with \u003ca href=\"https://csrc.nist.gov/pubs/fips/140-2/upd2/final#:~:text=This%20Federal%20Information%20Processing%20Standard,of%20potential%20applications%20and%20environments.\"\u003eFederal Information Processing Standards (FIPS) 140-2\u003c/a\u003e in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Concepts\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eKey Management Phases\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePre-Operational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eOperational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePost-Operational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDestroyed Phase\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendation for Key Management: Part 1 - General\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003ein Section 8, there are four phases of key management:\u003c/p\u003e\u003col\u003e\u003cli\u003e\u003cstrong\u003ePre-operational phase\u003c/strong\u003e: The keying material is not yet available for normal cryptographic operations. Keys may not yet be generated or are in the pre-activation state. System or enterprise attributes are established during this phase as well.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eOperational phase\u003c/strong\u003e: The keying material is available and in normal use. Keys are in the active or suspended state. Keys in the active state may be designated as protect only, process only, or both protect and process; keys in the suspended state can be used for processing only.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePost-operational phase\u003c/strong\u003e: The keying material is no longer in normal use, but access to the keying material is possible, and the keying material may be used for processing protected information. Keys are in the deactivated or compromised states. Keys in the post-operational phase may be in an archive.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eDestroyed phase: \u003c/strong\u003eKeys are no longer available. Records of their existence may or may not have been deleted. Keys are in the destroyed state. Although the keys themselves may have been destroyed, the key’s metadata (e.g., key name, type, cryptoperiod, and usage period) may be retained. A cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect.\u003c/li\u003e\u003c/ol\u003e\u003ch4\u003e\u003cstrong\u003eKey Establishment\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey establishment is the process that results in the sharing of a key between two or more entities. This process could be by a manual distribution, by using automated key-transport or key agreement mechanisms, or by key derivation using an already-shared key between or among those entities. Key establishment processes include the creation of a key. Key establishment techniques and issues are discussed in Section 5.3 of \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/175/b/r1/final\"\u003eNIST SP 800-175B \u003cem\u003eGuideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms\u003c/em\u003e.\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Management Functions\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eRoles and responsibilities need to be defined for the CMS management of at least the following functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe generation or acquisition of key information (i.e., keying material and the associated metadata)\u003c/li\u003e\u003cli\u003eThe secure distribution of private keys, secret keys and the associated metadata\u003c/li\u003e\u003cli\u003eThe establishment of cryptoperiods\u003c/li\u003e\u003cli\u003eKey and/or certificate inventory management, including procedures for the routine supersession of keys and certificates at the end of a cryptoperiod or validity period\u003c/li\u003e\u003cli\u003eProcedures for the emergency revocation of compromised keys and the establishment (e.g., distribution) of replacement keys and/or certificates\u003c/li\u003e\u003cli\u003eAccounting for and the storage and recovery of the operational and backed-up copies of key information\u003c/li\u003e\u003cli\u003eThe storage and recovery of archived key information\u003c/li\u003e\u003cli\u003eProcedures for checking the integrity of stored key information before using it\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe destruction of private or secret keys that are no longer required\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eCryptographic Key Management Systems (CKMS)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe term cryptographic key management system (CKMS) refers to the framework and services that provide for the generation, establishment, control, accounting, and destruction of cryptographic keys and associated management information.\u003c/p\u003e\u003cp\u003eIt includes all elements (hardware, software, other equipment, and documentation); facilities; personnel; procedures; standards; and information products that form the system that establishes, manages, and supports cryptographic products and services for end entities.\u003c/p\u003e\u003cp\u003eA CKMS may handle symmetric keys, asymmetric keys or both. Key management policies, practice statements, and specifications should identify common CKMS elements and suggest functions of and relationships among the organizational elements responsible for the management and use of cryptographic keys.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-152.pdf\"\u003eNIST SP 800-152\u003c/a\u003e contains requirements for the design, implementation, and procurement of a CKMS for the CMS organization. A key management system can be designed to provide services for a single individual (e.g., in a personal data-storage system), an organization (e.g., in a secure Virtual Private Network (VPN) for intraoffice communications), or a large complex of organizations (e.g., in secure communications for the U.S. Government).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Planning\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final\"\u003eNIST SP.800-57 Part 2 Revision 1\u003c/a\u003e, CMS organizations are required by statutory and administrative rules and guidelines to protect the confidentiality and integrity of their sensitive information and processes. Federal agencies are required to determine a \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf\"\u003eFIPS 200\u003c/a\u003e impact level (i.e., Low, Moderate or High) based on the security categories defined in \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFIPS 199\u003c/a\u003e. The security categories are based on the potential impact on an organization if certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.\u003c/p\u003e\u003cp\u003eCMS encourages Application Development Organizations (ADOs) to utilize software solutions (both on premises and in the Cloud) that help with the creation, identification, management, retrieval, rotation, and removal of keys - especially when these products help ADOs to better comply with CMS key management policy and its requirements.\u003c/p\u003e\u003cp\u003eCMS organizations also need to define their security objectives for storing and/or communicating their sensitive information. These objectives may include the following:\u003c/p\u003e\u003cul\u003e\u003cli\u003eProviding confidentiality for stored and/or transmitted data,\u003c/li\u003e\u003cli\u003eSource authentication for received data,\u003c/li\u003e\u003cli\u003eIntegrity protection for stored/transmitted data,\u003c/li\u003e\u003cli\u003eEntity authentication, etc.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe development of new cryptographic systems, including CKMS, should ideally be conducted following the processes described in \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/160/v2/r1/ipd#:~:text=Draft%20NIST%20Special%20Publication%20(SP,systems%20from%20the%20inside%20out\"\u003eNIST SP 800-160 \u003cem\u003eDeveloping Cyber-Resilient Systems: A Systems Security Engineering Approach\u003c/em\u003e\u003c/a\u003e. However, in many cases, systems that rely on cryptographic protection are already being used. Where such systems are being augmented or otherwise modified, security/privacy planning is still required, but the NIST SP 800-160 processes will need to be abridged or otherwise adapted because of legacy constraints. CMS organizations must still select \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53\u003c/a\u003e, based on \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eARS 5.0\u003c/a\u003e Control Catalog, security/privacy controls based on system design, operational characteristics, and FIPS 199 impact levels.\u003c/p\u003e\u003cp\u003eKey management planning should involve the following steps:\u003c/p\u003e\u003col\u003e\u003cli\u003eAn appropriate key management architecture is selected based on the available cryptographic mechanisms and objectives. Section 2.3 of \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf\"\u003eNIST SP 800-57 Part. 2 Revision 1\u003c/a\u003e provides examples of architectures to be considered.\u003c/li\u003e\u003cli\u003eA Key Management Specification is developed for each cryptographic product to be used in the system. When developing a Key Management Specification for a cryptographic product, the unique key management products and services needed from the CKMS to support the operation of the cryptographic product must be defined. The specification of cryptographic mechanisms, including key management functions, should consider the CMS organization’s resource limitations and procedural environment. If a Key Management Plan already exists for a CMS organization, the Key Management Specification needs to be in conformance with the CKMS Security Policy. The CKMS Practice Statement should support both the CKMS Security Policy and the Key Management Specification.\u003c/li\u003e\u003cli\u003eBased on the Key Management Plan, a CKMS Security Policy (CKMS SP) is developed that documents the decisions made in developing the Key Management Plan. A CKMS SP is a set of rules that are established to describe the goals, responsibilities, and overall requirements for the management of cryptographic keying material throughout the entire key lifecycle.\u003c/li\u003e\u003cli\u003eA CKMS may be operated by the organization owning the information to be protected, or may be operated by another organization (e.g., under contract). The organization operating the CKMS develops a CKMS Practice Statement (CKMS PS). A CKMS PS specifies how key management procedures and techniques are used to enforce the CKMS SP.\u003c/li\u003e\u003c/ol\u003e\u003ch3\u003e\u003cstrong\u003eKey Strength\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS organizations should consider the following best practices:\u003c/p\u003e\u003cul\u003e\u003cli\u003eEstablish what the application's minimum computational resistance to attack should be. Understanding the minimum computational resistance to attack should take into consideration the sophistication of your adversaries, how long data needs to be protected, where data is stored and if it is exposed. Identifying the computational resistance to attack will inform engineers as to the minimum length of the cryptographic key required to protect data over the life of that data. Consult \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/131/a/r2/final\"\u003eNIST SP 800-131a \u003cem\u003eTransitioning the Use of Cryptographic Algorithms and Key Lengths\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003efor additional guidance on determining the appropriate key lengths for the algorithm of choice.\u003c/li\u003e\u003cli\u003eWhen encrypting keys for storage or distribution, always encrypt a cryptographic key with another key of equal or greater cryptographic strength.\u003c/li\u003e\u003cli\u003eChoose a key length that meets or exceeds the comparative strength of other algorithms in use within your system. Refer to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57\u003c/a\u003e Table 2.\u003c/li\u003e\u003cli\u003eFormulate a strategy for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices.\u003c/li\u003e\u003cli\u003eReview \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendation for Key Management \u003c/em\u003e\u003c/a\u003efor recommended guidelines on key strength for specific algorithm implementations.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePublic Key Infrastructure\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePublic key infrastructure (PKI), as stated in \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-32.pdf\"\u003eNIST Special Publication 800-32: \u003cem\u003eIntroduction to Public Key Technology and the Federal PKI Infrastructure\u003c/em\u003e\u003c/a\u003e, is the combination of software, encryption technologies, and services that enables enterprises to \u003ca href=\"https://playbooks.idmanagement.gov/fpki/\"\u003eprotect the security of their communications and business transactions on networks\u003c/a\u003e. PKI integrates digital certificates, public key cryptography, and \u003cstrong\u003ecertification authorities (CA)\u003c/strong\u003e into a complete enterprise-wide network security architecture.\u003c/p\u003e\u003cp\u003eAll public key certificates used at CMS are issued in accordance with Federal PKI policy and validated to the Federal PKI trust anchor when being used for user signing, encrypting purposes, authentication, and authorization.\u003c/p\u003e\u003cp\u003eThe CA is responsible for issuing a public key certificate for each identity, confirming that the identity has the appropriate credentials. \u003cem\u003e\u003cstrong\u003eNote - \u003c/strong\u003ecertification authority (CA) is similar to a notary. The CA confirms the identities of parties sending and receiving electronic payments or other communications.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eAt CMS, various Certificate Authority requests are available and processed through the Infrastructure and User Services Group - Division of Operations Management (IUSG-DOM).\u003c/p\u003e\u003cp\u003eThere are two ways to submit a CA request for a certificate:\u003c/p\u003e\u003cul\u003e\u003cli\u003eRequestor submits a request through the CMS Connect System.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eNote: \u003c/strong\u003eOnly users with a CMS USER ID who have access to or VPN to the CMS Network will be able to login to the Agency Solution for Customer Support (ASCS). If you do not have a CMS USER ID, see option #2 below to submit an email request.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eRequestor sends certificate request email to the \u003cstrong\u003eCMS - DOMSSLCert \u003c/strong\u003emailbox at \u003ca href=\"mailto:DOMSSLCert@cms.hhs.gov\"\u003eDOMSSLCert@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor inquiries on the type of certificate to request, contact the CMS - DOMSSLCert mailbox at \u003ca href=\"mailto:DOMSSLCert@cms.hhs.gov\"\u003eDOMSSLCert@cms.hhs.gov\u003c/a\u003e for assistance.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Usage\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePer NIST SP 800-57 Part 1 Revision 5: \u003cem\u003eRecommendation for Key Management\u003c/em\u003e, a single key should be used for only one purpose (e.g., encryption, integrity authentication, key wrapping, random bit generation, or digital signatures).\u003c/p\u003e\u003cp\u003eThere are several reasons for this:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.\u003c/li\u003e\u003cli\u003eLimiting the use of a key limits the damage that could be done if the key is compromised.\u003c/li\u003e\u003cli\u003eSome uses of keys interfere with each other. For example, the length of time the key may be required for each use and purpose. Retention requirements of the data may differ for different data types.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis recommendation permits the use of a private key-transport or key-agreement key to generate a digital signature for the following special case: When requesting the (initial) certificate for a static key-establishment key that was generated as specified in \u003ca href=\"https://csrc.nist.gov/pubs/fips/186-5/final\"\u003eFIPS 186-5\u003c/a\u003e, the corresponding private key may be used to sign the certificate request.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Lifecycle Best Practices\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eGeneration\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCryptographic keys should be generated within cryptographic modules with at least a \u003ca href=\"https://csrc.nist.gov/pubs/fips/140-2/upd2/final\"\u003eFIPS 140-2\u003c/a\u003e compliance. For explanatory purposes, consider the cryptographic module in which a key is generated to be the key-generating module.\u003c/p\u003e\u003cp\u003eAny random value required by the key-generating module should be generated within that module; that is, the Random Bit Generator that generates the random value should be implemented within cryptographic modules with at least a FIPS 140-2 compliance that generates the key.\u003c/p\u003e\u003cp\u003eHardware cryptographic modules are preferred over software cryptographic modules for protection.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eUse/Distribution\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe generated keys should be transported (when necessary) using secure channels and should be used by their associated cryptographic algorithm within at least a FIPS 140-2 compliant cryptographic module. For additional detail for the recommendations in this section refer to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/133/r2/final\"\u003eNIST Special Publication 800-133\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eKeys or secrets should be shared out of band and should never be sent with or alongside the data the secrets or keys they are protecting. Also, secrets shared out-of-band should be protected and not stored somewhere that can be easily compromised (like on a piece of paper on a user’s desk). Out of band sharing of keys should be deleted or destroyed immediately after use.\u003c/p\u003e\u003cp\u003eADOs should also consider using a Diffie-Hellman algorithm like Secure-Remote Procedure Call (S-RPC) for the sharing of keys when out of band sharing is not a viable option. \u003cem\u003e\u003cstrong\u003eNote\u003c/strong\u003e - The Diffie–Hellman (DH) Algorithm is \u003cstrong\u003ea key-exchange protocol \u003c/strong\u003ethat enables two parties communicating over public channel to establish a mutual secret without it being transmitted over the Internet. DH enables the two to use a public key to encrypt and decrypt their conversation or data using symmetric cryptography.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eExamples of how keys can be shared included:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUse a Key or Secrets Management System\u003c/li\u003e\u003cli\u003eUse a shared key store or password manager vault\u003c/li\u003e\u003cli\u003eUse of client-side encrypted pastebin or similar service\u003c/li\u003e\u003cli\u003eUse of a restricted document\u003c/li\u003e\u003cli\u003eSending encrypted data via email (CMS adheres to the encryption requirements in the \u003ca href=\"https://intranet.hhs.gov/sites/default/files/s3fs-public/s3fs-public/policies-guides-encryption.pdf\"\u003eHHS Standard for Encryption of Computing Devices and Information\u003c/a\u003e)\u003c/li\u003e\u003cli\u003eUsing a third-party, CMS approved storage service\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eADOs should document the method being used for the business or system owner. ADOs are also encouraged to use TLS Version 1.2 or 1.3 encryption standards for Data-in-transit.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eStorage\u003c/strong\u003e\u003c/h4\u003e\u003cul\u003e\u003cli\u003eADOs should document in a Key Management Plan where secrets are being stored, and that documentation should be made available to the business or system owner, and updated as needed but no less than annually. The documentation should be written per system, define types of secrets used, list all secret alias names, creation date, recommended rotation date, level of sensitivity/classification, recommended end of use, business owner, and secret manager. The secrets should be encrypted and stored separately using a KMS solution or service.\u003c/li\u003e\u003cli\u003eCMS strongly encourages ADOs to use “split knowledge” or “M of N” for very sensitive key storage so that one individual does not have sole access to a key\u003c/li\u003e\u003cli\u003eDevelopers must understand where cryptographic keys are stored within the application and understand what memory devices the keys are stored on.\u003c/li\u003e\u003cli\u003eKeys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules.\u003c/li\u003e\u003cli\u003eKeys should never be stored in plaintext format.\u003c/li\u003e\u003cli\u003eEnsure all keys are stored in a cryptographic vault, such as a hardware security module (HSM), or isolated cryptographic service or secret management services.\u003c/li\u003e\u003cli\u003eIf you are planning on storing keys in offline devices/databases, then encrypt the keys using Key Encryption Keys (KEKs) prior to the export of the key material. KEK length (and algorithm) should be equivalent to or greater in strength than the keys being protected.\u003c/li\u003e\u003cli\u003eEnsure that keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Authentication Code (MAC)).\u003c/li\u003e\u003cli\u003eEnsure that standard application-level code never reads or uses cryptographic keys in any way and use key management libraries.\u003c/li\u003e\u003cli\u003eEnsure that keys and cryptographic operation is done inside a secure cryptographic vault.\u003c/li\u003e\u003cli\u003eAll work should be done in the cryptographic vault (such as key access, encryption, decryption, signing, etc.).\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eEscrow and Backup\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eData that has been encrypted with lost cryptographic keys will never be recovered. Therefore, it is essential that the application incorporate a secure key backup capability, especially for applications that support data-at-rest encryption for long-term data stores.\u003c/p\u003e\u003cp\u003eWhen backing up keys, ensure that the database that is used to store the keys is encrypted using at least a FIPS 140-2 validated module. It is sometimes useful to escrow key material for use in investigations and for re-provisioning of key material to users in the event that the key is lost or corrupted.\u003c/p\u003e\u003cp\u003eNever escrow keys used for performing digital signatures, but consider the need to escrow keys that support encryption. Oftentimes, escrow can be performed by the Certificate Authority (CA) or key management system that provisions certificates and keys, however in some instances separate APIs must be implemented to allow the system to perform the escrow for the application.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eAccountability and Audit\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAccountability involves the identification of those that have access to, or control of, cryptographic keys throughout their lifecycles. Accountability can be an effective tool to help prevent key compromises and to reduce the impact of compromises once they are detected.\u003c/p\u003e\u003cp\u003eAt a minimum, the key management system should account for all individuals who are able to view plaintext cryptographic keys.\u003c/p\u003e\u003cp\u003eIn addition, more sophisticated key-management systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form.\u003c/p\u003e\u003cp\u003eAccountability provides three significant advantages:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIt aids in the determination of when the compromise could have occurred and what individuals could have been involved.\u003c/li\u003e\u003cli\u003eIt tends to protect against compromise, because individuals with access to the key know that their access to the key is known.\u003c/li\u003e\u003cli\u003eIt is very useful in recovering from a detected key compromise to know where the key was used and what data or other keys were protected by the compromised key.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCertain principles have been found to be useful in enforcing the accountability of cryptographic keys. These principles might not apply to all systems or all types of keys.\u003c/p\u003e\u003cp\u003eSome of the principles that apply to long-term keys controlled by humans include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUniquely identifying keys.\u003c/li\u003e\u003cli\u003eIdentifying the key user.\u003c/li\u003e\u003cli\u003eIdentifying the dates and times of key use, along with the data that is protected.\u003c/li\u003e\u003cli\u003eIdentifying other keys that are protected by a symmetric or private key. Two types of audit should be performed on key management systems:\u003c/li\u003e\u003cli\u003eThe security/privacy plan and the procedures that are developed to support the plan should be periodically audited to ensure that they continue to support the Key Management Policy in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final\"\u003eNIST SP 800-57\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eThe protective mechanisms employed should be periodically reassessed with respect to the level of security that they provide and are expected to provide in the future, and that the mechanisms correctly and effectively support the appropriate policies.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNew technology developments and attacks should be taken into consideration. On a more frequent basis, the actions of the humans that use, operate, and maintain the system should be reviewed to verify that the humans continue to follow established security/privacy procedures.\u003c/p\u003e\u003cp\u003eStrong cryptographic systems can be compromised by lax and inappropriate human actions. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks on the system.\u003c/p\u003e\u003cp\u003eAccountability and Audit ensures the security objectives (Confidentiality, Integrity and Availability) are maintained. Effective integrity can be maintained if ADOs incorporate logging and provide for audit trails so we can track who used keys or secrets, for what purpose, etc.\u003c/p\u003e\u003cp\u003eIntegrity of the keys supports non-repudiation.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Rotation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey rotation provides several benefits, which are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIn the event that a key is compromised, regular rotation limits the number of actual messages/systems vulnerable to compromise. If key version is suspected to be compromised, disable it and revoke access to it as soon as possible.\u003c/li\u003e\u003cli\u003eRegular key rotation ensures CMS systems are resilient to manual rotation, whether due to a security breach or the need to migrate application to a stronger cryptographic algorithm.\u003c/li\u003e\u003cli\u003eLimiting the number of messages encrypted with the same key version helps prevent attacks enabled by cryptanalysis. Cryptanalysis is the study of ciphertext, ciphers and cryptosystems with the aim of understanding how they work and finding and improving techniques for defeating or weakening them.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor symmetric encryption, CMS organizations should configure automation key rotation by setting a key rotation period and starting time when key is created.\u003c/p\u003e\u003cp\u003eFor asymmetric encryption, CMS organizations should always manually rotate keys, because the new public key must be distributed before the key pair can be used.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRecommended minimum frequency of key rotation \u003c/strong\u003e– Annually.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNote \u003c/em\u003e- The rotation schedule can be based on either the key's age or the number or volume of messages encrypted with a key version. \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf\"\u003eNIST SP 800-57 Recommendation for Key Management \u003c/a\u003edescribes cryptoperiods as a factor in determining an appropriate period for rotation.\u003c/p\u003e\u003cp\u003eIf responsible personnel have indications that keys have been compromised, they should manually rotate the keys and re-encrypt data that was encrypted by the compromised keys as soon as possible. To re-encrypt data, download the old data, decrypt it with the old key, encrypt the old data using the new key, and then re-upload the re-encrypted data.\u003c/p\u003e\u003cp\u003eCMS recommends Online Certificate Status Protocol (OCSP) over Certificate Lifecycle Management (CLM) because there can be latencies in the system where CLM may not have the most up to date revocations.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Revocation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt2/final\"\u003eNIST SP 800-57 Part 2 \u003cem\u003eRecommendation for Key Management: Part 2 – Best Practices for Key Management Organizations\u003c/em\u003e\u003c/a\u003e, symmetric keys are often revoked by the use of Compromised Key Lists (CKLs). Certificate Revocation Lists (CRLs) are commonly used to revoke public key certificates, thus revoking the private key corresponding to the public key in the certificate. Regardless of whether symmetric or asymmetric keys are used, a means of revoking keys is recommended.\u003c/p\u003e\u003cp\u003eThis CMS guide will use the term revoked key notification (RKN) to refer to a mechanism to revoke keys. An RKN may include the revocation reason and an indication of when the revocation was requested. The inclusion of the revocation reason can be useful in risk decisions regarding the information that was received or stored using those keys.\u003c/p\u003e\u003cp\u003eA key may also be suspended from use for a variety of reasons, such as an unknown status of the key or due to the key owner being temporarily unavailable (e.g., the key owner is on extended leave). In the case of a certificate suspension, the intent is to suspend the use of the public key included in the certificate (e.g., to not verify digital signatures or establish keys while the use of the certificate is suspended). This may be communicated to relying parties as an “on hold” revocation reason code in a CRL and in an OCSP response. The certificate may later be revoked (e.g., a compromise of the private key corresponding to the public key in the certificate was confirmed) or the certificate may be reactivated (e.g., the key has not been compromised or the owner returned to work).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCompromise of Keys\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey compromise occurs when the protective mechanisms for the key fail (e.g., the confidentiality, integrity, or association of the key to its owner fail;) and the key can no longer be trusted to provide the required security. It is the responsibility of an owner of a private or secret key to protect the confidentiality of that key. Reporting a possible key compromise is the responsibility of anyone suspecting that a key has been compromised (e.g., the key’s owner or an entity that observes that the data protected by that key has been compromised).\u003c/p\u003e\u003cp\u003eWhen a key is compromised, all use of the key to apply cryptographic protection to information (e.g., compute a digital signature or encrypt information) should cease, and the compromised key should be revoked.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eGuidelines to Minimize the Likelihood of a Key Compromise\u003c/strong\u003e\u003c/h4\u003e\u003cul\u003e\u003cli\u003ePeriodically rotate keys per the recommendation in this guide;\u003c/li\u003e\u003cli\u003eLimiting the amount of time that a secret symmetric or asymmetric private key is in plaintext form;\u003c/li\u003e\u003cli\u003ePreventing humans from viewing plaintext secret symmetric and asymmetric private keys;\u003c/li\u003e\u003cli\u003eRestricting plaintext secret and private keys to physically protected “containers.” This includes key generators, key-transport devices, key loaders, cryptographic modules, hardware security modules (HSMs), and key-storage devices;\u003c/li\u003e\u003cli\u003eUsing integrity checks to ensure that the integrity of a key or its association with other data has not been compromised. For example, keys may be wrapped (i.e., encrypted and integrity protected) in such a manner that unauthorized modifications to the wrapped key or to the key’s metadata will be detected;\u003cul\u003e\u003cli\u003eProviding a cryptographic integrity check on the key (e.g., using a MAC or a digital signature);\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eEmploying key confirmation to help ensure that the proper key was, in fact, established;\u003c/li\u003e\u003cli\u003eUsing trusted timestamps for signed data;\u003c/li\u003e\u003cli\u003eDestroying keys as soon as they are no longer needed; and\u003c/li\u003e\u003cli\u003eCreating a compromise-recovery plan, especially in the case of the compromise of a CA key.\u003c/li\u003e\u003cli\u003eData (key) dispersion - Data dispersion is recommended either through Redundant Array of Independent Disks (RAID) or use of erasure coding (bit splitting) in the Cloud. Data dispersion also addresses potential legal complications (for Cloud applications) that could arise should a server be confiscated by law enforcement. \u003cstrong\u003eNote -\u003c/strong\u003e\u003cem\u003e RAID (redundant array of independent disks) is a way of storing the same data in different places on multiple hard disks or solid-state drives (SSDs) to protect data in the case of a drive failure.\u003c/em\u003e\u003c/li\u003e\u003cli\u003eSSMS (Secret Sharing Made Short) is another standard protocol that is encouraged for key management within Cloud application. \u003cstrong\u003eNote -\u003c/strong\u003e \u003cem\u003eSSMS uses a three-phase process: encryption of information; use of information dispersal algorithm (IDA), which is designed to efficiently split the data using erasure coding into fragments; and splitting the encryption key itself using the secret-sharing algorithm.\u003c/em\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eA compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan should be documented and easily accessible. The plan may be included in a Key-Management Practices Statement39. If not, the Key-Management Practices Statement should reference the compromise-recovery plan.\u003c/p\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final\"\u003eNIST SP 800-57 Part 1 Rev. 5\u003c/a\u003e, a compromise-recovery plan should contain:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAn identification of the personnel to notify and what the notification should contain (e.g., the scope of the compromise − whether specific keys were compromised or the certificate generation process was compromised);\u003c/li\u003e\u003cli\u003eAn identification of the personnel to perform the recovery actions;\u003c/li\u003e\u003cli\u003eThe method for obtaining a new key (i.e., re-keying);\u003c/li\u003e\u003cli\u003eAn inventory of all cryptographic keys (e.g., the location of all keys and certificates in a system);\u003c/li\u003e\u003cli\u003eThe education of all appropriate personnel on the compromise-recovery procedures;\u003c/li\u003e\u003cli\u003eAn identification of all personnel needed to support the compromise-recovery procedures;\u003c/li\u003e\u003cli\u003ePolicies requiring that key-revocation checking be performed (to minimize the effect of a compromise);\u003c/li\u003e\u003cli\u003eThe monitoring of the re-keying operations (to ensure that all required operations are performed for all affected keys); and\u003c/li\u003e\u003cli\u003eAny other compromise-recovery procedures.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eOther compromise-recovery procedures may include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA physical inspection of the equipment;\u003c/li\u003e\u003cli\u003eAn identification of all information that may be compromised as a result of the incident;\u003c/li\u003e\u003cli\u003eAn identification of all signatures that may be invalid due to the compromise of a signing key; and\u003c/li\u003e\u003cli\u003eThe distribution of new keying material, if required.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eKey Archive and Key Recovery Functions\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eA key archive is a repository containing keys and their associated information (i.e., key information) for recovery beyond the cryptoperiod of the keys. Not all keys need to be archived. A CMS organization’s security/privacy plan should discuss key archiving.\u003c/p\u003e\u003cp\u003eAccess to key archive should be limited to authorized personnel/entities.\u003c/p\u003e\u003cp\u003eIf a key must be recoverable (e.g., after the end of its cryptoperiod), either the key should be archived, or the system should be designed to allow reconstruction (e.g., re-derivation) of the key from archived information. Retrieving the key from archive storage or by reconstruction is commonly known as key recovery. The archive should be maintained by a trusted party (e.g., the CMS organization associated with the key or a trusted third party).\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote -\u003c/strong\u003e \u003cem\u003eA cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys or a given system will remain in effect.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eNIST Special Publication \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf\"\u003e800-57 Part 1, Revision 5 \u003cem\u003eRecommendation for Key Management: Part 1 – General\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003efurther addresses the appropriateness of archiving keys and other cryptographically related information.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTrust Store\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eA trust store is a repository that contains cryptographic artifacts like certificates and private keys that are used for cryptographic protocols such as TLS. Because the compromise of a cryptographic key compromises all of the information and processes protected by that key, it is essential that client nodes be able to trust that keys and/or key components come from a trusted source, and that their confidentiality (if required) and integrity have been protected both in storage and in transit.\u003c/p\u003e"])</script><script>self.__next_f.push([1,"25:Tb185,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eBackground\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook aligns with the \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNational Institute of Standards and Technology (NIST) Special Publication (SP) 800-57\u003c/a\u003e series, the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS IS2P2\u003c/a\u003e, and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS Acceptable Risk Safeguards (ARS)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://security.cms.gov/learn/federal-information-systems-management-act-fisma\"\u003eFISMA\u003c/a\u003e further emphasizes the importance of continuously monitoring information system security by requiring agencies to conduct assessments of security controls at a risk-defined frequency. The CMS ARS states that CMS information systems must define, develop, disseminate, review, and update its Risk Assessment documentation at least once every three years or whenever a significant change has occurred. This includes a formal, documented system security/privacy package that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and formal, documented processes and procedures to facilitate the implementation of the policy and associated controls.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePolicy\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePolicy delineates the security management structure, clearly assigns security responsibilities, and lays the foundation necessary to reliably measure progress, compliance, and direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems or systems maintained on behalf of CMS to assure the confidentiality, integrity, and availability of CMS information and information systems.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eInformation Systems Security and Privacy Policy (IS2P2)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS IS2P2\u003c/a\u003e defines the framework and policy under which CMS protects and controls access to CMS information and information systems in compliance with the Department of Human and Health Services (HHS) policy, federal law, and regulations. This policy requires all CMS stakeholders to implement adequate information security and privacy safeguards to protect all CMS's sensitive information.\u003c/p\u003e\u003cp\u003eThe policies contained within the CMS IS2P2 assist in satisfying the requirements for controls that require CMS to create a policy and associated procedures related to information systems.\u003c/p\u003e\u003cp\u003eThe dynamic nature of information security and privacy disciplines and the constant need for assessing risk across the CMS environment can result in gaps in policy, outside of the routine policy review cycle. The CMS Policy Framework includes the option to issue a \u003ca href=\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/Policies\"\u003eCIO Directive\u003c/a\u003e to address these types of gaps in CMS policy by providing guidance to CMS stakeholders while a policy is being developed, updated, cleared, and approved.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eChief Information Officer (CIO) Directives\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CMS Chief Information Officer (CIO), the CMS Chief Information Security Officer (CISO), and the CMS Senior Official for Privacy (SOP) jointly develop and maintain the CMS IS2P2. The CIO delegates authority and responsibility to specific organizations and officials within CMS to develop and administer defined aspects of the CMS Information Security and Privacy Program as appropriate.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eStandards\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eStandards define both functional and assurance requirements within the CMS security and privacy environment. CMS policy is executed with the requirements prescribed in standards with the objective of enabling consistency across the CMS environment. The CMS environment includes users, networks, devices, all software, processes, information in storage or transit, applications, services, and systems that can be connected directly or indirectly to networks. These components are responsible for meeting and complying with the security and privacy baseline defined in policy and further prescribed in standards. The parameters and thresholds for policy implementation are built into the CMS standards, and provide a foundation for the procedural guidance provided by the Program Guide series.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eSecrets Management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eA secret is a digital authentication credential. Secrets are individually named sets of sensitive information, and address a broad spectrum of secure data. Secrets need to be protected against unauthorized disclosure, and all keys need to be protected against modification, tempering, deletion and disclosure. There are different types of secrets, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUser passwords\u003c/li\u003e\u003cli\u003eRoot passwords\u003c/li\u003e\u003cli\u003eApplication and database passwords\u003c/li\u003e\u003cli\u003eAuto-generated encryption keys\u003c/li\u003e\u003cli\u003ePrivate encryption keys\u003c/li\u003e\u003cli\u003eApplication Programming Interface (API) keys\u003c/li\u003e\u003cli\u003eApplication keys\u003c/li\u003e\u003cli\u003eSecure Shell (SSH) keys\u003c/li\u003e\u003cli\u003eIAM secret keys\u003c/li\u003e\u003cli\u003eProgrammatic access keys (project / client IDs)\u003c/li\u003e\u003cli\u003eAuthorization tokens\u003c/li\u003e\u003cli\u003eBearer tokens\u003c/li\u003e\u003cli\u003eCertificates\u003c/li\u003e\u003cli\u003ePrivate certificates (e.g. Transport Layer Security (TLS), Secure Sockets Layer (SSL))\u003c/li\u003e\u003cli\u003eRSA and other one-time password devices\u003c/li\u003e\u003cli\u003eAccount tags\u003c/li\u003e\u003cli\u003ePassphrases\u003c/li\u003e\u003cli\u003eAny other application tokens that are deemed confidential\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSecrets management refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.\u003c/p\u003e\u003cp\u003ePasswords and keys are some of the most broadly used and important tools your organization has for authenticating applications and users and providing them with access to sensitive systems, services, and information. Because secrets have to be transmitted securely, secrets management must account for and mitigate the risks to these secrets, both in transit and at rest.\u003c/p\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eNote – \u003c/strong\u003eRoot access keys should be protected at all costs and deleted if possible. A bad actor may shut down servers, delete data, create and destroy users, or any other API capability with the root user’s key. For this reason, CMS highly recommends that root access key should not be in use or should be disabled if already in use. CMS also recommends keeping the root user’s credentials safe and private. Do not share them with other employees or contractors. It is also advisable to activate Multi Factor Authentication (MFA) for the root account to protect it even if the password leaks. Also, access and secret access keys should only be developed at a user level, and never at a root level.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThe security objectives (Confidentiality, Integrity and Availability) should always be protected in regards to secrets management. The \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFederal Information Processing Standards (FIPS) Publication 199\u003c/a\u003e defines three levels of potential impact on organizations or individuals (low, moderate, high) should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability) and has additional examples on the impact of loss of one or more of the security objectives.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eKey Management\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eKey management refers to managing cryptographic keys within a cryptosystem. The term “cryptosystem” is shorthand for “cryptographic system” and refers to a computer system that employs cryptography, a method of protecting information and communications through the use of codes so that only those for whom the information is intended can read and process it.\u003c/p\u003e\u003cp\u003eCryptosystems deal with generating, exchanging, storing, using and replacing keys as needed at the user level.\u003c/p\u003e\u003cp\u003eThe security of the cryptosystem is dependent upon successful key management. Proper management ensures a key stays safe throughout its lifecycle, from generation and use to storing and deletion.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCryptographic Keys\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography.\u003c/p\u003e\u003cp\u003eWith effective cryptographic key management, data that is encrypted can still be protected even in the event of a breach, since encrypted data cannot be decrypted without the right keys. Proper usage of encryption and key management will assist an organization’s efforts to protect their data. \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendations for Key Management (Part 1, Revision 5) \u003c/em\u003e\u003c/a\u003eprovides an updated guideline for general cryptographic key management.\u003c/p\u003e\u003cp\u003eAt CMS, mechanisms are employed to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eProhibit the use of encryption keys that are not recoverable by authorized personnel\u003c/li\u003e\u003cli\u003eRequire senior management approval to authorize recovery of keys by someone other than the key owner\u003c/li\u003e\u003cli\u003eComply with approved cryptography standards mentioned in transit and at rest, as defined in the HHS Standard for Encryption of Computing Devices and Information, and in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAt CMS, cryptographic protection applies to both portable storage devices (e.g., USB memory sticks, CDs, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers). This applies to all digital assets like application software, Data Stores (Such as databases and file systems), Cloud Service, and Software As a Service.\u003c/p\u003e\u003cp\u003eWhen cryptographic mechanisms are needed, CMS information systems use encryption products that have been validated under the Cryptographic Module Validation Program to confirm compliance with \u003ca href=\"https://csrc.nist.gov/pubs/fips/140-2/upd2/final#:~:text=This%20Federal%20Information%20Processing%20Standard,of%20potential%20applications%20and%20environments.\"\u003eFederal Information Processing Standards (FIPS) 140-2\u003c/a\u003e in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Concepts\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eKey Management Phases\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePre-Operational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eOperational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePost-Operational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDestroyed Phase\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendation for Key Management: Part 1 - General\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003ein Section 8, there are four phases of key management:\u003c/p\u003e\u003col\u003e\u003cli\u003e\u003cstrong\u003ePre-operational phase\u003c/strong\u003e: The keying material is not yet available for normal cryptographic operations. Keys may not yet be generated or are in the pre-activation state. System or enterprise attributes are established during this phase as well.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eOperational phase\u003c/strong\u003e: The keying material is available and in normal use. Keys are in the active or suspended state. Keys in the active state may be designated as protect only, process only, or both protect and process; keys in the suspended state can be used for processing only.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePost-operational phase\u003c/strong\u003e: The keying material is no longer in normal use, but access to the keying material is possible, and the keying material may be used for processing protected information. Keys are in the deactivated or compromised states. Keys in the post-operational phase may be in an archive.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eDestroyed phase: \u003c/strong\u003eKeys are no longer available. Records of their existence may or may not have been deleted. Keys are in the destroyed state. Although the keys themselves may have been destroyed, the key’s metadata (e.g., key name, type, cryptoperiod, and usage period) may be retained. A cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect.\u003c/li\u003e\u003c/ol\u003e\u003ch4\u003e\u003cstrong\u003eKey Establishment\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey establishment is the process that results in the sharing of a key between two or more entities. This process could be by a manual distribution, by using automated key-transport or key agreement mechanisms, or by key derivation using an already-shared key between or among those entities. Key establishment processes include the creation of a key. Key establishment techniques and issues are discussed in Section 5.3 of \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/175/b/r1/final\"\u003eNIST SP 800-175B \u003cem\u003eGuideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms\u003c/em\u003e.\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Management Functions\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eRoles and responsibilities need to be defined for the CMS management of at least the following functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe generation or acquisition of key information (i.e., keying material and the associated metadata)\u003c/li\u003e\u003cli\u003eThe secure distribution of private keys, secret keys and the associated metadata\u003c/li\u003e\u003cli\u003eThe establishment of cryptoperiods\u003c/li\u003e\u003cli\u003eKey and/or certificate inventory management, including procedures for the routine supersession of keys and certificates at the end of a cryptoperiod or validity period\u003c/li\u003e\u003cli\u003eProcedures for the emergency revocation of compromised keys and the establishment (e.g., distribution) of replacement keys and/or certificates\u003c/li\u003e\u003cli\u003eAccounting for and the storage and recovery of the operational and backed-up copies of key information\u003c/li\u003e\u003cli\u003eThe storage and recovery of archived key information\u003c/li\u003e\u003cli\u003eProcedures for checking the integrity of stored key information before using it\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe destruction of private or secret keys that are no longer required\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eCryptographic Key Management Systems (CKMS)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe term cryptographic key management system (CKMS) refers to the framework and services that provide for the generation, establishment, control, accounting, and destruction of cryptographic keys and associated management information.\u003c/p\u003e\u003cp\u003eIt includes all elements (hardware, software, other equipment, and documentation); facilities; personnel; procedures; standards; and information products that form the system that establishes, manages, and supports cryptographic products and services for end entities.\u003c/p\u003e\u003cp\u003eA CKMS may handle symmetric keys, asymmetric keys or both. Key management policies, practice statements, and specifications should identify common CKMS elements and suggest functions of and relationships among the organizational elements responsible for the management and use of cryptographic keys.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-152.pdf\"\u003eNIST SP 800-152\u003c/a\u003e contains requirements for the design, implementation, and procurement of a CKMS for the CMS organization. A key management system can be designed to provide services for a single individual (e.g., in a personal data-storage system), an organization (e.g., in a secure Virtual Private Network (VPN) for intraoffice communications), or a large complex of organizations (e.g., in secure communications for the U.S. Government).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Planning\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final\"\u003eNIST SP.800-57 Part 2 Revision 1\u003c/a\u003e, CMS organizations are required by statutory and administrative rules and guidelines to protect the confidentiality and integrity of their sensitive information and processes. Federal agencies are required to determine a \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf\"\u003eFIPS 200\u003c/a\u003e impact level (i.e., Low, Moderate or High) based on the security categories defined in \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFIPS 199\u003c/a\u003e. The security categories are based on the potential impact on an organization if certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.\u003c/p\u003e\u003cp\u003eCMS encourages Application Development Organizations (ADOs) to utilize software solutions (both on premises and in the Cloud) that help with the creation, identification, management, retrieval, rotation, and removal of keys - especially when these products help ADOs to better comply with CMS key management policy and its requirements.\u003c/p\u003e\u003cp\u003eCMS organizations also need to define their security objectives for storing and/or communicating their sensitive information. These objectives may include the following:\u003c/p\u003e\u003cul\u003e\u003cli\u003eProviding confidentiality for stored and/or transmitted data,\u003c/li\u003e\u003cli\u003eSource authentication for received data,\u003c/li\u003e\u003cli\u003eIntegrity protection for stored/transmitted data,\u003c/li\u003e\u003cli\u003eEntity authentication, etc.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe development of new cryptographic systems, including CKMS, should ideally be conducted following the processes described in \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/160/v2/r1/ipd#:~:text=Draft%20NIST%20Special%20Publication%20(SP,systems%20from%20the%20inside%20out\"\u003eNIST SP 800-160 \u003cem\u003eDeveloping Cyber-Resilient Systems: A Systems Security Engineering Approach\u003c/em\u003e\u003c/a\u003e. However, in many cases, systems that rely on cryptographic protection are already being used. Where such systems are being augmented or otherwise modified, security/privacy planning is still required, but the NIST SP 800-160 processes will need to be abridged or otherwise adapted because of legacy constraints. CMS organizations must still select \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53\u003c/a\u003e, based on \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eARS 5.0\u003c/a\u003e Control Catalog, security/privacy controls based on system design, operational characteristics, and FIPS 199 impact levels.\u003c/p\u003e\u003cp\u003eKey management planning should involve the following steps:\u003c/p\u003e\u003col\u003e\u003cli\u003eAn appropriate key management architecture is selected based on the available cryptographic mechanisms and objectives. Section 2.3 of \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf\"\u003eNIST SP 800-57 Part. 2 Revision 1\u003c/a\u003e provides examples of architectures to be considered.\u003c/li\u003e\u003cli\u003eA Key Management Specification is developed for each cryptographic product to be used in the system. When developing a Key Management Specification for a cryptographic product, the unique key management products and services needed from the CKMS to support the operation of the cryptographic product must be defined. The specification of cryptographic mechanisms, including key management functions, should consider the CMS organization’s resource limitations and procedural environment. If a Key Management Plan already exists for a CMS organization, the Key Management Specification needs to be in conformance with the CKMS Security Policy. The CKMS Practice Statement should support both the CKMS Security Policy and the Key Management Specification.\u003c/li\u003e\u003cli\u003eBased on the Key Management Plan, a CKMS Security Policy (CKMS SP) is developed that documents the decisions made in developing the Key Management Plan. A CKMS SP is a set of rules that are established to describe the goals, responsibilities, and overall requirements for the management of cryptographic keying material throughout the entire key lifecycle.\u003c/li\u003e\u003cli\u003eA CKMS may be operated by the organization owning the information to be protected, or may be operated by another organization (e.g., under contract). The organization operating the CKMS develops a CKMS Practice Statement (CKMS PS). A CKMS PS specifies how key management procedures and techniques are used to enforce the CKMS SP.\u003c/li\u003e\u003c/ol\u003e\u003ch3\u003e\u003cstrong\u003eKey Strength\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS organizations should consider the following best practices:\u003c/p\u003e\u003cul\u003e\u003cli\u003eEstablish what the application's minimum computational resistance to attack should be. Understanding the minimum computational resistance to attack should take into consideration the sophistication of your adversaries, how long data needs to be protected, where data is stored and if it is exposed. Identifying the computational resistance to attack will inform engineers as to the minimum length of the cryptographic key required to protect data over the life of that data. Consult \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/131/a/r2/final\"\u003eNIST SP 800-131a \u003cem\u003eTransitioning the Use of Cryptographic Algorithms and Key Lengths\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003efor additional guidance on determining the appropriate key lengths for the algorithm of choice.\u003c/li\u003e\u003cli\u003eWhen encrypting keys for storage or distribution, always encrypt a cryptographic key with another key of equal or greater cryptographic strength.\u003c/li\u003e\u003cli\u003eChoose a key length that meets or exceeds the comparative strength of other algorithms in use within your system. Refer to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57\u003c/a\u003e Table 2.\u003c/li\u003e\u003cli\u003eFormulate a strategy for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices.\u003c/li\u003e\u003cli\u003eReview \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendation for Key Management \u003c/em\u003e\u003c/a\u003efor recommended guidelines on key strength for specific algorithm implementations.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePublic Key Infrastructure\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePublic key infrastructure (PKI), as stated in \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-32.pdf\"\u003eNIST Special Publication 800-32: \u003cem\u003eIntroduction to Public Key Technology and the Federal PKI Infrastructure\u003c/em\u003e\u003c/a\u003e, is the combination of software, encryption technologies, and services that enables enterprises to \u003ca href=\"https://playbooks.idmanagement.gov/fpki/\"\u003eprotect the security of their communications and business transactions on networks\u003c/a\u003e. PKI integrates digital certificates, public key cryptography, and \u003cstrong\u003ecertification authorities (CA)\u003c/strong\u003e into a complete enterprise-wide network security architecture.\u003c/p\u003e\u003cp\u003eAll public key certificates used at CMS are issued in accordance with Federal PKI policy and validated to the Federal PKI trust anchor when being used for user signing, encrypting purposes, authentication, and authorization.\u003c/p\u003e\u003cp\u003eThe CA is responsible for issuing a public key certificate for each identity, confirming that the identity has the appropriate credentials. \u003cem\u003e\u003cstrong\u003eNote - \u003c/strong\u003ecertification authority (CA) is similar to a notary. The CA confirms the identities of parties sending and receiving electronic payments or other communications.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eAt CMS, various Certificate Authority requests are available and processed through the Infrastructure and User Services Group - Division of Operations Management (IUSG-DOM).\u003c/p\u003e\u003cp\u003eThere are two ways to submit a CA request for a certificate:\u003c/p\u003e\u003cul\u003e\u003cli\u003eRequestor submits a request through the CMS Connect System.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eNote: \u003c/strong\u003eOnly users with a CMS USER ID who have access to or VPN to the CMS Network will be able to login to the Agency Solution for Customer Support (ASCS). If you do not have a CMS USER ID, see option #2 below to submit an email request.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eRequestor sends certificate request email to the \u003cstrong\u003eCMS - DOMSSLCert \u003c/strong\u003emailbox at \u003ca href=\"mailto:DOMSSLCert@cms.hhs.gov\"\u003eDOMSSLCert@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor inquiries on the type of certificate to request, contact the CMS - DOMSSLCert mailbox at \u003ca href=\"mailto:DOMSSLCert@cms.hhs.gov\"\u003eDOMSSLCert@cms.hhs.gov\u003c/a\u003e for assistance.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Usage\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePer NIST SP 800-57 Part 1 Revision 5: \u003cem\u003eRecommendation for Key Management\u003c/em\u003e, a single key should be used for only one purpose (e.g., encryption, integrity authentication, key wrapping, random bit generation, or digital signatures).\u003c/p\u003e\u003cp\u003eThere are several reasons for this:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.\u003c/li\u003e\u003cli\u003eLimiting the use of a key limits the damage that could be done if the key is compromised.\u003c/li\u003e\u003cli\u003eSome uses of keys interfere with each other. For example, the length of time the key may be required for each use and purpose. Retention requirements of the data may differ for different data types.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis recommendation permits the use of a private key-transport or key-agreement key to generate a digital signature for the following special case: When requesting the (initial) certificate for a static key-establishment key that was generated as specified in \u003ca href=\"https://csrc.nist.gov/pubs/fips/186-5/final\"\u003eFIPS 186-5\u003c/a\u003e, the corresponding private key may be used to sign the certificate request.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Lifecycle Best Practices\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eGeneration\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCryptographic keys should be generated within cryptographic modules with at least a \u003ca href=\"https://csrc.nist.gov/pubs/fips/140-2/upd2/final\"\u003eFIPS 140-2\u003c/a\u003e compliance. For explanatory purposes, consider the cryptographic module in which a key is generated to be the key-generating module.\u003c/p\u003e\u003cp\u003eAny random value required by the key-generating module should be generated within that module; that is, the Random Bit Generator that generates the random value should be implemented within cryptographic modules with at least a FIPS 140-2 compliance that generates the key.\u003c/p\u003e\u003cp\u003eHardware cryptographic modules are preferred over software cryptographic modules for protection.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eUse/Distribution\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe generated keys should be transported (when necessary) using secure channels and should be used by their associated cryptographic algorithm within at least a FIPS 140-2 compliant cryptographic module. For additional detail for the recommendations in this section refer to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/133/r2/final\"\u003eNIST Special Publication 800-133\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eKeys or secrets should be shared out of band and should never be sent with or alongside the data the secrets or keys they are protecting. Also, secrets shared out-of-band should be protected and not stored somewhere that can be easily compromised (like on a piece of paper on a user’s desk). Out of band sharing of keys should be deleted or destroyed immediately after use.\u003c/p\u003e\u003cp\u003eADOs should also consider using a Diffie-Hellman algorithm like Secure-Remote Procedure Call (S-RPC) for the sharing of keys when out of band sharing is not a viable option. \u003cem\u003e\u003cstrong\u003eNote\u003c/strong\u003e - The Diffie–Hellman (DH) Algorithm is \u003cstrong\u003ea key-exchange protocol \u003c/strong\u003ethat enables two parties communicating over public channel to establish a mutual secret without it being transmitted over the Internet. DH enables the two to use a public key to encrypt and decrypt their conversation or data using symmetric cryptography.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eExamples of how keys can be shared included:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUse a Key or Secrets Management System\u003c/li\u003e\u003cli\u003eUse a shared key store or password manager vault\u003c/li\u003e\u003cli\u003eUse of client-side encrypted pastebin or similar service\u003c/li\u003e\u003cli\u003eUse of a restricted document\u003c/li\u003e\u003cli\u003eSending encrypted data via email (CMS adheres to the encryption requirements in the \u003ca href=\"https://intranet.hhs.gov/sites/default/files/s3fs-public/s3fs-public/policies-guides-encryption.pdf\"\u003eHHS Standard for Encryption of Computing Devices and Information\u003c/a\u003e)\u003c/li\u003e\u003cli\u003eUsing a third-party, CMS approved storage service\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eADOs should document the method being used for the business or system owner. ADOs are also encouraged to use TLS Version 1.2 or 1.3 encryption standards for Data-in-transit.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eStorage\u003c/strong\u003e\u003c/h4\u003e\u003cul\u003e\u003cli\u003eADOs should document in a Key Management Plan where secrets are being stored, and that documentation should be made available to the business or system owner, and updated as needed but no less than annually. The documentation should be written per system, define types of secrets used, list all secret alias names, creation date, recommended rotation date, level of sensitivity/classification, recommended end of use, business owner, and secret manager. The secrets should be encrypted and stored separately using a KMS solution or service.\u003c/li\u003e\u003cli\u003eCMS strongly encourages ADOs to use “split knowledge” or “M of N” for very sensitive key storage so that one individual does not have sole access to a key\u003c/li\u003e\u003cli\u003eDevelopers must understand where cryptographic keys are stored within the application and understand what memory devices the keys are stored on.\u003c/li\u003e\u003cli\u003eKeys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules.\u003c/li\u003e\u003cli\u003eKeys should never be stored in plaintext format.\u003c/li\u003e\u003cli\u003eEnsure all keys are stored in a cryptographic vault, such as a hardware security module (HSM), or isolated cryptographic service or secret management services.\u003c/li\u003e\u003cli\u003eIf you are planning on storing keys in offline devices/databases, then encrypt the keys using Key Encryption Keys (KEKs) prior to the export of the key material. KEK length (and algorithm) should be equivalent to or greater in strength than the keys being protected.\u003c/li\u003e\u003cli\u003eEnsure that keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Authentication Code (MAC)).\u003c/li\u003e\u003cli\u003eEnsure that standard application-level code never reads or uses cryptographic keys in any way and use key management libraries.\u003c/li\u003e\u003cli\u003eEnsure that keys and cryptographic operation is done inside a secure cryptographic vault.\u003c/li\u003e\u003cli\u003eAll work should be done in the cryptographic vault (such as key access, encryption, decryption, signing, etc.).\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eEscrow and Backup\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eData that has been encrypted with lost cryptographic keys will never be recovered. Therefore, it is essential that the application incorporate a secure key backup capability, especially for applications that support data-at-rest encryption for long-term data stores.\u003c/p\u003e\u003cp\u003eWhen backing up keys, ensure that the database that is used to store the keys is encrypted using at least a FIPS 140-2 validated module. It is sometimes useful to escrow key material for use in investigations and for re-provisioning of key material to users in the event that the key is lost or corrupted.\u003c/p\u003e\u003cp\u003eNever escrow keys used for performing digital signatures, but consider the need to escrow keys that support encryption. Oftentimes, escrow can be performed by the Certificate Authority (CA) or key management system that provisions certificates and keys, however in some instances separate APIs must be implemented to allow the system to perform the escrow for the application.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eAccountability and Audit\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAccountability involves the identification of those that have access to, or control of, cryptographic keys throughout their lifecycles. Accountability can be an effective tool to help prevent key compromises and to reduce the impact of compromises once they are detected.\u003c/p\u003e\u003cp\u003eAt a minimum, the key management system should account for all individuals who are able to view plaintext cryptographic keys.\u003c/p\u003e\u003cp\u003eIn addition, more sophisticated key-management systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form.\u003c/p\u003e\u003cp\u003eAccountability provides three significant advantages:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIt aids in the determination of when the compromise could have occurred and what individuals could have been involved.\u003c/li\u003e\u003cli\u003eIt tends to protect against compromise, because individuals with access to the key know that their access to the key is known.\u003c/li\u003e\u003cli\u003eIt is very useful in recovering from a detected key compromise to know where the key was used and what data or other keys were protected by the compromised key.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCertain principles have been found to be useful in enforcing the accountability of cryptographic keys. These principles might not apply to all systems or all types of keys.\u003c/p\u003e\u003cp\u003eSome of the principles that apply to long-term keys controlled by humans include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUniquely identifying keys.\u003c/li\u003e\u003cli\u003eIdentifying the key user.\u003c/li\u003e\u003cli\u003eIdentifying the dates and times of key use, along with the data that is protected.\u003c/li\u003e\u003cli\u003eIdentifying other keys that are protected by a symmetric or private key. Two types of audit should be performed on key management systems:\u003c/li\u003e\u003cli\u003eThe security/privacy plan and the procedures that are developed to support the plan should be periodically audited to ensure that they continue to support the Key Management Policy in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final\"\u003eNIST SP 800-57\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eThe protective mechanisms employed should be periodically reassessed with respect to the level of security that they provide and are expected to provide in the future, and that the mechanisms correctly and effectively support the appropriate policies.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNew technology developments and attacks should be taken into consideration. On a more frequent basis, the actions of the humans that use, operate, and maintain the system should be reviewed to verify that the humans continue to follow established security/privacy procedures.\u003c/p\u003e\u003cp\u003eStrong cryptographic systems can be compromised by lax and inappropriate human actions. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks on the system.\u003c/p\u003e\u003cp\u003eAccountability and Audit ensures the security objectives (Confidentiality, Integrity and Availability) are maintained. Effective integrity can be maintained if ADOs incorporate logging and provide for audit trails so we can track who used keys or secrets, for what purpose, etc.\u003c/p\u003e\u003cp\u003eIntegrity of the keys supports non-repudiation.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Rotation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey rotation provides several benefits, which are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIn the event that a key is compromised, regular rotation limits the number of actual messages/systems vulnerable to compromise. If key version is suspected to be compromised, disable it and revoke access to it as soon as possible.\u003c/li\u003e\u003cli\u003eRegular key rotation ensures CMS systems are resilient to manual rotation, whether due to a security breach or the need to migrate application to a stronger cryptographic algorithm.\u003c/li\u003e\u003cli\u003eLimiting the number of messages encrypted with the same key version helps prevent attacks enabled by cryptanalysis. Cryptanalysis is the study of ciphertext, ciphers and cryptosystems with the aim of understanding how they work and finding and improving techniques for defeating or weakening them.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor symmetric encryption, CMS organizations should configure automation key rotation by setting a key rotation period and starting time when key is created.\u003c/p\u003e\u003cp\u003eFor asymmetric encryption, CMS organizations should always manually rotate keys, because the new public key must be distributed before the key pair can be used.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRecommended minimum frequency of key rotation \u003c/strong\u003e– Annually.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNote \u003c/em\u003e- The rotation schedule can be based on either the key's age or the number or volume of messages encrypted with a key version. \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf\"\u003eNIST SP 800-57 Recommendation for Key Management \u003c/a\u003edescribes cryptoperiods as a factor in determining an appropriate period for rotation.\u003c/p\u003e\u003cp\u003eIf responsible personnel have indications that keys have been compromised, they should manually rotate the keys and re-encrypt data that was encrypted by the compromised keys as soon as possible. To re-encrypt data, download the old data, decrypt it with the old key, encrypt the old data using the new key, and then re-upload the re-encrypted data.\u003c/p\u003e\u003cp\u003eCMS recommends Online Certificate Status Protocol (OCSP) over Certificate Lifecycle Management (CLM) because there can be latencies in the system where CLM may not have the most up to date revocations.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Revocation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt2/final\"\u003eNIST SP 800-57 Part 2 \u003cem\u003eRecommendation for Key Management: Part 2 – Best Practices for Key Management Organizations\u003c/em\u003e\u003c/a\u003e, symmetric keys are often revoked by the use of Compromised Key Lists (CKLs). Certificate Revocation Lists (CRLs) are commonly used to revoke public key certificates, thus revoking the private key corresponding to the public key in the certificate. Regardless of whether symmetric or asymmetric keys are used, a means of revoking keys is recommended.\u003c/p\u003e\u003cp\u003eThis CMS guide will use the term revoked key notification (RKN) to refer to a mechanism to revoke keys. An RKN may include the revocation reason and an indication of when the revocation was requested. The inclusion of the revocation reason can be useful in risk decisions regarding the information that was received or stored using those keys.\u003c/p\u003e\u003cp\u003eA key may also be suspended from use for a variety of reasons, such as an unknown status of the key or due to the key owner being temporarily unavailable (e.g., the key owner is on extended leave). In the case of a certificate suspension, the intent is to suspend the use of the public key included in the certificate (e.g., to not verify digital signatures or establish keys while the use of the certificate is suspended). This may be communicated to relying parties as an “on hold” revocation reason code in a CRL and in an OCSP response. The certificate may later be revoked (e.g., a compromise of the private key corresponding to the public key in the certificate was confirmed) or the certificate may be reactivated (e.g., the key has not been compromised or the owner returned to work).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCompromise of Keys\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey compromise occurs when the protective mechanisms for the key fail (e.g., the confidentiality, integrity, or association of the key to its owner fail;) and the key can no longer be trusted to provide the required security. It is the responsibility of an owner of a private or secret key to protect the confidentiality of that key. Reporting a possible key compromise is the responsibility of anyone suspecting that a key has been compromised (e.g., the key’s owner or an entity that observes that the data protected by that key has been compromised).\u003c/p\u003e\u003cp\u003eWhen a key is compromised, all use of the key to apply cryptographic protection to information (e.g., compute a digital signature or encrypt information) should cease, and the compromised key should be revoked.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eGuidelines to Minimize the Likelihood of a Key Compromise\u003c/strong\u003e\u003c/h4\u003e\u003cul\u003e\u003cli\u003ePeriodically rotate keys per the recommendation in this guide;\u003c/li\u003e\u003cli\u003eLimiting the amount of time that a secret symmetric or asymmetric private key is in plaintext form;\u003c/li\u003e\u003cli\u003ePreventing humans from viewing plaintext secret symmetric and asymmetric private keys;\u003c/li\u003e\u003cli\u003eRestricting plaintext secret and private keys to physically protected “containers.” This includes key generators, key-transport devices, key loaders, cryptographic modules, hardware security modules (HSMs), and key-storage devices;\u003c/li\u003e\u003cli\u003eUsing integrity checks to ensure that the integrity of a key or its association with other data has not been compromised. For example, keys may be wrapped (i.e., encrypted and integrity protected) in such a manner that unauthorized modifications to the wrapped key or to the key’s metadata will be detected;\u003cul\u003e\u003cli\u003eProviding a cryptographic integrity check on the key (e.g., using a MAC or a digital signature);\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eEmploying key confirmation to help ensure that the proper key was, in fact, established;\u003c/li\u003e\u003cli\u003eUsing trusted timestamps for signed data;\u003c/li\u003e\u003cli\u003eDestroying keys as soon as they are no longer needed; and\u003c/li\u003e\u003cli\u003eCreating a compromise-recovery plan, especially in the case of the compromise of a CA key.\u003c/li\u003e\u003cli\u003eData (key) dispersion - Data dispersion is recommended either through Redundant Array of Independent Disks (RAID) or use of erasure coding (bit splitting) in the Cloud. Data dispersion also addresses potential legal complications (for Cloud applications) that could arise should a server be confiscated by law enforcement. \u003cstrong\u003eNote -\u003c/strong\u003e\u003cem\u003e RAID (redundant array of independent disks) is a way of storing the same data in different places on multiple hard disks or solid-state drives (SSDs) to protect data in the case of a drive failure.\u003c/em\u003e\u003c/li\u003e\u003cli\u003eSSMS (Secret Sharing Made Short) is another standard protocol that is encouraged for key management within Cloud application. \u003cstrong\u003eNote -\u003c/strong\u003e \u003cem\u003eSSMS uses a three-phase process: encryption of information; use of information dispersal algorithm (IDA), which is designed to efficiently split the data using erasure coding into fragments; and splitting the encryption key itself using the secret-sharing algorithm.\u003c/em\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eA compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan should be documented and easily accessible. The plan may be included in a Key-Management Practices Statement39. If not, the Key-Management Practices Statement should reference the compromise-recovery plan.\u003c/p\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final\"\u003eNIST SP 800-57 Part 1 Rev. 5\u003c/a\u003e, a compromise-recovery plan should contain:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAn identification of the personnel to notify and what the notification should contain (e.g., the scope of the compromise − whether specific keys were compromised or the certificate generation process was compromised);\u003c/li\u003e\u003cli\u003eAn identification of the personnel to perform the recovery actions;\u003c/li\u003e\u003cli\u003eThe method for obtaining a new key (i.e., re-keying);\u003c/li\u003e\u003cli\u003eAn inventory of all cryptographic keys (e.g., the location of all keys and certificates in a system);\u003c/li\u003e\u003cli\u003eThe education of all appropriate personnel on the compromise-recovery procedures;\u003c/li\u003e\u003cli\u003eAn identification of all personnel needed to support the compromise-recovery procedures;\u003c/li\u003e\u003cli\u003ePolicies requiring that key-revocation checking be performed (to minimize the effect of a compromise);\u003c/li\u003e\u003cli\u003eThe monitoring of the re-keying operations (to ensure that all required operations are performed for all affected keys); and\u003c/li\u003e\u003cli\u003eAny other compromise-recovery procedures.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eOther compromise-recovery procedures may include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA physical inspection of the equipment;\u003c/li\u003e\u003cli\u003eAn identification of all information that may be compromised as a result of the incident;\u003c/li\u003e\u003cli\u003eAn identification of all signatures that may be invalid due to the compromise of a signing key; and\u003c/li\u003e\u003cli\u003eThe distribution of new keying material, if required.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eKey Archive and Key Recovery Functions\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eA key archive is a repository containing keys and their associated information (i.e., key information) for recovery beyond the cryptoperiod of the keys. Not all keys need to be archived. A CMS organization’s security/privacy plan should discuss key archiving.\u003c/p\u003e\u003cp\u003eAccess to key archive should be limited to authorized personnel/entities.\u003c/p\u003e\u003cp\u003eIf a key must be recoverable (e.g., after the end of its cryptoperiod), either the key should be archived, or the system should be designed to allow reconstruction (e.g., re-derivation) of the key from archived information. Retrieving the key from archive storage or by reconstruction is commonly known as key recovery. The archive should be maintained by a trusted party (e.g., the CMS organization associated with the key or a trusted third party).\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote -\u003c/strong\u003e \u003cem\u003eA cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys or a given system will remain in effect.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eNIST Special Publication \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf\"\u003e800-57 Part 1, Revision 5 \u003cem\u003eRecommendation for Key Management: Part 1 – General\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003efurther addresses the appropriateness of archiving keys and other cryptographically related information.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTrust Store\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eA trust store is a repository that contains cryptographic artifacts like certificates and private keys that are used for cryptographic protocols such as TLS. Because the compromise of a cryptographic key compromises all of the information and processes protected by that key, it is essential that client nodes be able to trust that keys and/or key components come from a trusted source, and that their confidentiality (if required) and integrity have been protected both in storage and in transit.\u003c/p\u003e"])</script><script>self.__next_f.push([1,"26:T12321,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook gives practical guidance to Information System Security Officers (ISSO)s at CMS when performing their necessary tasks.\u0026nbsp; It helps new ISSOs get started and explains the responsibilities, resources, and organizational relationships needed for an ISSO to be successful.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis guide is for CMS (Federal) ISSOs, Contractor ISSOs, and contract security support individuals.\u0026nbsp; Business Owners and their staff may also find parts of this handbook useful, particularly when appointing new ISSOs or gaining a better understanding of ISSO tasks.\u003c/p\u003e\u003cp\u003eThe ISSO role is critical to the safe and authorized use of sensitive information in support of CMS’ commitment to improving healthcare for millions of Americans. As an ISSO,\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat do ISSOs do?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eEvery CMS system must formally designate an ISSO who serves as the primary point of contact responsible for the system’s security and privacy.\u0026nbsp;\u003c/p\u003e\u003cp\u003eISSOs at CMS are responsible for overseeing the security and privacy posture of the system(s) entrusted to their care, coordinating all information system risk management and information privacy activities, and acting as the Business Owner’s “go-to person” for security questions and needs. Together, the ISSOs make up a supportive community working to ensure the success of the cybersecurity program at CMS.\u003c/p\u003e\u003cp\u003eFor more details, see the section on role and responsibilities.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho do ISSOs work with?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO is part of the\u003cstrong\u003e portfolio team\u003c/strong\u003e – the group of people who work together to make sure that any given CMS information system complies with federal security requirements and is managed in a way that protects the personal and health information of those who depend on CMS for benefits. The portfolio team has the following roles:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProgram Executive, Information System Owner (ISO), Business Owner (BO), and Information System Security Officer (ISSO)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThese people work together to take full responsibility for implementing the required security and privacy controls and managing the cybersecurity and privacy risk posture for each system. All of these roles must be an agency official (federal government employee) except the ISSO, which may be a federal employee or a contractor.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCyber Risk Advisor (CRA)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eCRAs are the “go-to” experts in all areas of risk management, and as such they evaluate and communicate the risk posture of each FISMA system to executive leadership and make risk-based recommendations to the Authorizing Official. CRAs also help to identify the types of information processed by a system, assign the appropriate security categorizations, determine the privacy impacts, and manage information security and privacy risk. They facilitate the completion of all federal cybersecurity and privacy requirements – and this means that CRAs and ISSOs often work closely together.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eData Guardian\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Data Guardian coordinates CMS Program activities involving beneficiary and other types of consumer information that require privacy protections.\u0026nbsp; The Data Guardian must be an agency official (federal government employee) and must fulfill shared responsibilities with the CMS Business Owner.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePrivacy Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Privacy Advisor is a member of ISPG who provides privacy-related expertise to help the team identify and manage privacy risk.\u0026nbsp; The Privacy Advisor is an agency official (federal government employee) and serves as a point of contact for issues related to the Privacy Act. They also support the completion of privacy-related artifacts such as Systems of Records Notice (SORN), Privacy Act reviews, and FISMA and Privacy Management Report.\u003c/p\u003e\u003cp\u003eDetailed information about all of these roles can be found in the CMS Information Security and Privacy Policy (IS2P2) and the HHS Policy for Information Security and Privacy Protection (IS2P).\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat should an ISSO know?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe goal of every ISSO should be to support the BO to securely provide the service intended by the system. To help accomplish this goal, an ISSO should ideally know and understand their component’s business processes and how the system supports that business. This knowledge is critically applied during the construction of the System Security and Privacy Plan (SSPP).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eInformation security is a means to an end and not the end in itself\u003c/strong\u003e. In the public sector, information security is secondary to the agency's services provided to its constituency. We, as security professionals, must not lose sight of these goals and objectives.\u003c/p\u003e\u003cp\u003eIn order to help the BO provide a CMS service in a manner that is demonstrably secure and safeguards any sensitive beneficiary information, the ISSO must know (at a minimum):\u003c/p\u003e\u003cul\u003e\u003cli\u003eMission and business functions of their component\u003c/li\u003e\u003cli\u003eHow the system supports the component’s mission\u003c/li\u003e\u003cli\u003eSystem details, including:\u003cul\u003e\u003cli\u003eArchitecture\u003c/li\u003e\u003cli\u003eSystem components (hardware, software, peripherals, etc.)\u003c/li\u003e\u003cli\u003eLocation of each system component\u003c/li\u003e\u003cli\u003eData flow\u003c/li\u003e\u003cli\u003eInterconnections (internal and external)\u003c/li\u003e\u003cli\u003eSecurity categorization\u0026nbsp;\u003c/li\u003e\u003cli\u003eSecurity requirements\u003c/li\u003e\u003cli\u003eConfiguration management processes and procedures\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eUsers (how many, location, role, etc.)\u003c/li\u003e\u003cli\u003eKey personnel by name\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eHow are ISSOs appointed?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CMS Program Executive in coordination with the Data Guardian, ISO, and Business Owner, is responsible for nominating appropriately qualified ISSO appointees, as defined under FISMA, to the CISO for approval.\u003c/p\u003e\u003cp\u003eThe nominated ISSO, by signing the appointment letter, agrees to maintain the appropriate operational security posture of the information system by fulfilling all of the responsibilities identified in the \u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS Information Security and Privacy Policy (IS2P2)\u003c/a\u003e and the HHS Policy for Information Security and Privacy Protection (IS2P).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eA subset of the ISSO’s duties and responsibilities is contained in the \u003ca href=\"/learn/isso-appointment-letter\"\u003eappointment letter\u003c/a\u003e. ISSO letters must be updated whenever a change occurs. The designated ISSO should be consistently identified in three sources: the ISSO letter, the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e, and in \u003ca href=\"/learn/cms-fisma-continuous-tracking-system-cfacts\"\u003eCFACTS\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe signed appointment letter should be given to the appropriate CRA for further action.\u0026nbsp;\u003cstrong\u003e It is the responsibility of the CRA to upload the letter to CFACTS\u003c/strong\u003e.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eGetting started (for new ISSOs)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCongratulations on your new assignment as an Information System Security Officer (ISSO) at CMS! Because you are charged with protecting the sensitive information contained in systems that support healthcare delivery for millions of people, your role is vital to the success of CMS’ mission. You will learn how to identify and protect information that includes:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePersonally Identifiable Information (PII)\u003c/li\u003e\u003cli\u003eIndividually Identifiable Information (IIF)\u003c/li\u003e\u003cli\u003eProtected Health Information (PHI)\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis means that security must become a vital part of your daily routine and always top-of-mind. Your training as an ISSO will ensure that you know and understand the requirements for protecting government assets like classified information, property, and personnel.\u003c/p\u003e\u003cp\u003eMost importantly, you will learn to work as part of a team that is dedicated to making sure CMS information systems can operate securely. While CMS has established a security program to protect assets and keep sensitive information safe, the key ingredient is always \u003cstrong\u003epeople\u003c/strong\u003e. No matter how comprehensive a program may be, you and your coworkers will ultimately determine the success of our established procedures.\u0026nbsp;\u003c/p\u003e\u003cp\u003eAnd we are here to help you along the way! This Handbook is your primary resource for initial information about your role, and will direct you to other sources of help and support.\u003c/p\u003e\u003cp\u003eHere are the steps you should take to get started:\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eComplete the paperwork\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIf you have not already, make sure that your \u003ca href=\"/learn/isso-appointment-letter\"\u003e\u003cstrong\u003eISSO Appointment Letter\u003c/strong\u003e\u003c/a\u003e is completed and submitted to your Cyber Risk Advisor (CRA) by your Business Owner (BO). The Appointment Letter is intended to formally nominate you as an ISSO. It also gives you a wealth of information about your duties and responsibilities. It also contains the qualifications and training to which you should aspire. This document may be your first communication with your CRA — the first of many conversations.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf you need a copy of the ISSO Appointment Letter template, contact the ISSO Support Team: \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eComplete ISSO onboarding\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO Support team in ISPG can help get you started. You should ask for an initial meeting with the team to orient you to your new role and next steps. \u0026nbsp; You should also reach out to your CRA, who may wish to meet on a regular basis initially, especially if your system has an important near-term milestone. If your BO did not set this up for you, you can do it yourself by sending a note to \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e. It is helpful to put the word “Onboarding” in the subject line.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKnow your systems\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eMake sure that in your conversation with your Business Owner, you understand whether you are going to be the primary ISSO (or the only ISSO), or if you are going to be an assistant. Do you know where your system is located? When does the Authority to Operate (ATO) expire? Are you working on a new system? The more you know at the beginning, the easier it will be to prioritize and to work with your integrated team. If you have questions about any of this, reach out to the ISSO Support Team (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMeet your team\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIn addition to your BO and your CRA, there are others that you should get to know. We recommend that you reach out to them. We also recommend face to face meetings, at least initially. Some others you should get to know include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eOther ISSOs in your component, if applicable\u003c/li\u003e\u003cli\u003eYour system’s Technical Lead\u003c/li\u003e\u003cli\u003eWhen appropriate, your system’s contractor security support\u003c/li\u003e\u003cli\u003eThe ISSO Support Team (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAssess your skills with the ISSO Score Card\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eISSOs come from many backgrounds, both technical and non-technical. Even new ISSOs with a technical background may not be familiar with the “CMS way” of operating. While you will be busy with your new role, you should take some initial time to get a better awareness of your capabilities to be a CMS ISSO through some focused initial training.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWe’ve made it easy to figure out what training you should prioritize using a self-assessment tool: the \u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eISSO Score Card.\u003c/a\u003e Every ISSO is encouraged to take this assessment regularly as their knowledge expands. The ISSO Score Card is:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eConfidential\u003c/strong\u003e - only you will see the results\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eQuick\u003c/strong\u003e - only taking 10-15 minutes to complete\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eGeared to ISSO duties\u003c/strong\u003e - taken directly from CMS policies and requirements\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePersonalized\u003c/strong\u003e - you’ll get a customized report to help you make a training plan\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eEasy\u003c/strong\u003e - using a simple online web interface\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eGo to the ISSO Score Card\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eSign up for training\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAs an ISSO, it is vital that you understand security and privacy fundamentals and how they are applied at CMS. Regardless of your prior level of experience, you will need to know the CMS-specific workflows and governance. There is a wealth of training available to you, both for getting started and deepening your knowledge.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eWondering where to start\u003c/strong\u003e? Here’s a simple checklist to make sure you complete the essential training that will start you on the road to success:\u003c/p\u003e\u003cul\u003e\u003cli\u003eFigure out what you need to know (or brush up on) using the \u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eISSO Score Card\u003c/a\u003e. Use the results to sign up for training that is customized to your level.\u003c/li\u003e\u003cli\u003eLearn about 6 key job functions of ISSOs using the \u003ca href=\"https://www.cms.gov/cbt/login/default.aspx\"\u003evideo training series from CMS\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eSign up for CFACTS training – it’s worth the 2-day time investment to get a solid grasp on this essential tool for the ISSO’s daily work. (This is available in the CMS Computer Based Training platform).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFinally, to build upon the checklist above, we have provided a list of Basic, Intermediate, and Advanced ISSO training courses that are free for you to take. See the Training section of this Handbook for details.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eGet a mentor\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOptionally, you can join the \u003ca href=\"/learn/isso-mentorship-program\"\u003e\u003cstrong\u003eISSO Mentorship Program\u003c/strong\u003e\u003c/a\u003e to be paired with an experienced ISSO. Once paired, you should work together to develop a cadence for meeting and knowledge sharing. This allows you to gain confidence faster and get hands-on support. Learn more about the ISSO Mentorship Program here.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eJoin the community\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe cybersecurity community at CMS is alive and growing. There are all kinds of ways that you can get involved, get an idea of what’s going on at CMS, and learn how it affects you. Attend the CMS Cybersecurity Community Forum, read the ISSO Journal, and look for ISPG-sponsored security and privacy activities.\u003c/p\u003e\u003cp\u003eFinally, if you have any questions along the way, just ask. Your job is very important to the success of CMS programs, and everyone at ISPG is here to support you!\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eGoals for your first year\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eBy the end of your first year as an ISSO, it should be your goal to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eLearn the security planning and administrative security procedures for systems that process sensitive information such as PHI, PII, FTI, and classified and national intelligence data\u003c/li\u003e\u003cli\u003eUnderstand the implementation and enforcement of CMS’ Information System Security and Privacy policies and practices\u0026nbsp;\u003c/li\u003e\u003cli\u003eKnow the concerns and requirements that determine the administration and management of physical, system, and data access controls based on the sensitivity of the data processed and the corresponding authorization requirements\u003c/li\u003e\u003cli\u003eLearn the identification, analysis, assessment and evaluation of information system threats and vulnerabilities and their impact on their component’s critical information infrastructures\u003c/li\u003e\u003cli\u003eBe able to identify management, technical, personnel, operational and physical security controls\u003c/li\u003e\u003cli\u003eUnderstand any additional critical areas of knowledge related to your system\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eRole and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eISSOs maintain a strong security and privacy posture for their assigned system(s) in the following high-level ways:\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eServe as principal advisor\u003c/strong\u003e to the System Owner (SO), Business Owner (BO), and the Chief Information Security Officer (CISO) on all system security and privacy matters\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMaintain system authorization \u003c/strong\u003eby following the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-risk-management-framework-rmf\"\u003eNIST Risk Management Framework\u003c/a\u003e to select, implement, document, test, and maintain the security and privacy controls required to authorize and operate information systems within CMS’s risk tolerance throughout the \u003ca href=\"https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/tlc\"\u003eTarget Life Cycle\u003c/a\u003e (TLC)\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMaintain security and privacy operations\u003c/strong\u003e capabilities sufficient to identify, detect, protect, respond, and recover from security incidents (as per the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-cybersecurity-framework-csf\"\u003eNIST Cybersecurity Framework\u003c/a\u003e)\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMeet federal reporting requirements\u003c/strong\u003e for information security and privacy, including documenting and mitigating weaknesses and reporting incidents and breaches\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eManage privacy requirements\u003c/strong\u003e by working collaboratively with Data Guardians and Privacy Advisors\u003c/p\u003e\u003cp\u003eThe official role and specific responsibilities for ISSOs are outlined in detail by the CMS Information Security and Privacy Policy (IS2P2), which is based upon the related policy document from HHS (IS2P). The following list is based on those policy documents and includes some key duties for ISSOs:\u003c/p\u003e\u003cul\u003e\u003cli\u003eComplete the security categorization for the FISMA system using the CFACTS tool\u003c/li\u003e\u003cli\u003eComplete and maintain the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan\u003c/a\u003e using the CFACTS tool\u003c/li\u003e\u003cli\u003eEnsure \u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e – and \u003ca href=\"/learn/penetration-testing\"\u003ePenetration Tests\u003c/a\u003e have been scheduled and completed in a timely manner\u003c/li\u003e\u003cli\u003eDevelop, document and maintain an inventory of hardware and software components within the FISMA system’s authorization boundary\u003c/li\u003e\u003cli\u003eCoordinate the development of a \u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan\u003c/a\u003e and ensure the plan is tested and maintained accordingly\u003c/li\u003e\u003cli\u003eMaintain primary responsibility for the actions and activities associated with the FISMA system receiving and maintaining an \u003ca href=\"/learn/authorization-operate-ato\"\u003eAuthority to Operate (ATO)\u003c/a\u003e\u003c/li\u003e\u003cli\u003eCoordinate with the ISO, BO, and CRA to manage information security and privacy risk\u003c/li\u003e\u003cli\u003eMonitor and update all POA\u0026amp;Ms in accordance with current requirements and instruction\u003c/li\u003e\u003cli\u003eSubmit recommendations to the CRA for system configuration deviations from the required baseline\u003c/li\u003e\u003cli\u003eIdentify the information security and privacy controls provided by the applicable infrastructure that are common controls for information systems;\u003c/li\u003e\u003cli\u003eCoordinate with the ISO, BO, and CRA to meet all collection, creation, use, dissemination, retention, and maintenance requirements for sensitive information in accordance with the Privacy Act, E-Government Act, and all other applicable guidance\u003c/li\u003e\u003cli\u003eCoordinate with the BO, Contracting Officer, ISO, and CISO to ensure that all requirements specified by the \u003ca href=\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eARS 5.1\u003c/a\u003e and the \u003ca href=\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\"\u003eRMH\u003c/a\u003e are implemented and enforced for applicable information and information systems\u003c/li\u003e\u003cli\u003eReport and manage IT Security and Privacy Incidents in accordance to the RMH and other applicable federal guidance\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eTypes of ISSO roles\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe specific type of ISSO role assigned to a system will depend on the needs of the system and the available personnel. The descriptions below are taken from the CMS Information Security and Privacy Policy (IS2P2).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrimary Information System Security Officer (P-ISSO)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS P-ISSO may be either a federal government employee or a contractor and must fulfill all of the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.24, System Security and System Privacy Officers. ISSO must ensure the duties of the Security Control Assessor and Contingency Planning Coordinator are completed as described in the IS2P Sections 7.26 and 7.30.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecondary Information System Security Officer (S-ISSO)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS S-ISSO may be either a federal government employee or a contractor identified in the IS2P Section 7.25, ISSO Designated Representative / Security Steward and must assist the P-ISSO.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInformation System Security Officer Contractor Support (ISSOCS)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe ISSOCS is a contractor-only role that assists and supports the P-ISSO and S-ISSO roles in fulfillment of their CMS cybersecurity duties.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity or Privacy Control Assessor\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Security or Privacy Control Assessor role may be performed by an ISSO. The CMS Security or Privacy Control Assessor must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.23.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eContingency Planning Coordinator\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Contingency Planning Coordinator may either be a federal government employee or a contractor. The role may also be performed by an ISSO. The CMS Contingency Planning Coordinator must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.30.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eISSO checklist\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThis section provides a list of specific tasks an ISSO should perform periodically. The timelines listed for each task are general guidelines, which may vary depending on the Component guidance or system circumstances. This list isn’t comprehensive, but serves as a quick reference to help you plan your work. You may choose to make a spreadsheet for yourself to keep track of recurring tasks and due dates.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eWeekly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview audit logs\u003c/li\u003e\u003cli\u003eRoutinely evaluate risk posture based upon change requests\u003c/li\u003e\u003cli\u003eEnsure data is backed up\u003c/li\u003e\u003cli\u003eCheck status of any \u003ca href=\"/learn/plan-action-and-milestones-poam\"\u003ePlan of Action and Milestones (POA\u0026amp;M)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eMonthly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview / deactivate unused accounts\u003c/li\u003e\u003cli\u003eEnsure all POA\u0026amp;Ms with Open or Delay status are annotated with current status\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eQuarterly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsure that all data in CFACTS is current and accurate one week before the end of the quarter (CMS submits a quarterly FISMA report to OMB based on this data)\u003c/li\u003e\u003cli\u003eEnsure the completion of internal vulnerability scans\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eAnnually\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview and update all \u003cstrong\u003eSecurity Authorization Process documentation\u003c/strong\u003e, such as those listed below. Remember that most of these require months of effort to complete, so you must be working on them well in advance.\u003cul\u003e\u003cli\u003e\u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eInformation System Risk Assessment (ISRA)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan (CP)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePrivacy Impact Assessment (PIA)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e Note: Updating security control implementation is a necessary first step to updating the SSPP. When updating any documents, ensure the old copy is retained.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eEnsure that all system users and people with significant security responsibilities (e.g., ISSOs) receive their required annual awareness training\u003c/li\u003e\u003cli\u003eConduct a Contingency Plan Test with associated training, after-action, and updated POA\u0026amp;Ms as necessary. Ensure that the Business Owner certifies (signs) any updated CP document.\u003c/li\u003e\u003cli\u003eReview the Privacy Impact Assessment (PIA) for your system(s) and update as appropriate\u003c/li\u003e\u003cli\u003eEnsure vulnerability assessments are completed at least annually, or when significant changes are made to the system\u003c/li\u003e\u003cli\u003eReview and validate user access rights\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOngoing\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eContinual security control assessment to ensure no risks are present\u003c/li\u003e\u003cli\u003eContinual work on tests and assessments (as needed) such as:\u003cul\u003e\u003cli\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/li\u003e\u003cli\u003ePenetration Testing\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eContinual updating of the \u003cstrong\u003eSecurity Authorization Process documentation\u003c/strong\u003e (see list in the section above). All of these should be updated as changes occur, and all require an annual review and update.\u003c/li\u003e\u003cli\u003eComplete incident response reports (as required)\u003c/li\u003e\u003cli\u003eATO updates (as required)\u003c/li\u003e\u003cli\u003eRespond to any CCIC monitoring alerts (as required)\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eISSO activities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eUse this section to learn in-depth about the activities you must understand and perform as an ISSO – from the very beginning of your system’s development. These activities support the CMS \u003ca href=\"https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/tlc\"\u003eTarget Life Cycle\u003c/a\u003e (TLC), which is the framework that standardizes how IT systems are built, maintained, and retired at CMS. The ISSO activities also support the Risk Management Framework (RMF) from NIST, which helps organizations integrate security considerations into their software development processes.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eConduct a Security Impact Analysis (SIA)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe \u003ca href=\"/learn/security-impact-analysis-sia\"\u003eSecurity Impact Analysis\u003c/a\u003e\u0026nbsp;is the process that you will use initially for your new system and \u003cstrong\u003eevery time\u003c/strong\u003e a new change to the system is proposed. When you have completed this process, you will be able to provide substantive recommendations to your Business Owner on the impact of any proposed change(s). The impact may be small, or it may rise to the level of a new ATO process.\u003c/p\u003e\u003cp\u003eNote:\u0026nbsp; SIAs are frequently thought of as documents.\u0026nbsp; Remember that \u003cstrong\u003eSIA is a process\u003c/strong\u003e.\u0026nbsp; Based on the complexity and extent of the process, a completed form may help better describe the security impact, as well as necessary actions to take.\u0026nbsp; The actual CMS/FISMA requirement noted in ARS 5.1 Control CM-4 requires “Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) to conduct security impact analyses.”\u0026nbsp; It is up to you and your Business Owner/organization to determine the level to which you document your analysis.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-impact-analysis-sia\"\u003eLearn about Security Impact Assessment (SIA)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCategorize your FISMA system\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eYour FISMA system has different security controls based on the sensitivity of the information contained in or processed by your system. Categorization takes place within CFACTS.\u0026nbsp; You enter the appropriate area and select the type of information that will be processed.\u0026nbsp; The system categorization will be suggested automatically and noted as “Low”, “Moderate”, or “High”.\u0026nbsp; If necessary, the categorization may be manually overridden; your CRA will have to help with this.\u0026nbsp; In practice this seldom happens.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis system categorization will have a variety of uses.\u0026nbsp; Most importantly, you will need to have this information to determine which controls to allocate for your system.\u003c/p\u003e\u003cp\u003eNote: Although this process sounds like it will only be done once for your FISMA system, \u003cstrong\u003eyou may have to repeat it\u003c/strong\u003e if a proposed change includes access or storage of different types of data. \u0026nbsp; Your completed SIA will guide your actions.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/federal-information-security-modernization-act-fisma#perform-system-risk-categorization\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eLearn more about system categorization here\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/posts/watch-and-learn-system-categorization-cfacts\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eSee how to categorize your system in CFACTS\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eDetermine the Authorization Boundary\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAnother major initial task is to determine the system’s \u003cstrong\u003eAuthorization Boundary\u003c/strong\u003e. The NIST definition of authorization boundary is: “All components of an information system to be authorized for operation by an authorizing official and excludes separately authorized systems, to which the information system is connected”.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eOne practical way of determining the system’s authorization boundary is to ask whether a particular component can be changed by one’s system team, or if another team has to make updates or changes.\u0026nbsp; If your team can make the change or configuration, chances are that the component falls within your authorization boundary. As with system categorization, the authorization boundary is usually determined at the outset of system development. It may expand or contract based on changes to the system over its lifecycle.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBe aware of High Value Assets (HVAs)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe HHS HVA Program Policy defines HVAs as: “Assets, federal information systems, information, and data for which an unauthorized access, use, disclosure, disruption, modification, or destruction could cause a significant impact to the United States’ national security interests, foreign relations, economy, or to the public confidence, civil liberties, or public health and safety of the American people.”\u003c/p\u003e\u003cp\u003eThe practical impact of this program is that, if your FISMA system is defined as an HVA, it will face additional security requirements from DHS and HHS, which may impact the continuity operations and assessments of the system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAllocate controls\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOnce a system has been categorized, the ISSO has the information necessary to select controls, or allocate them.\u0026nbsp; The process is largely automatic, and is well-described in the CMS Risk Management Handbook (RMH) Chapter 12: Security and Privacy Planning. Selected controls are allocated for Low, Moderate, or High systems based on system categorization. The mechanics are described very well in the CFACTS User Manual, so that should be your primary reference point on allocating controls. Some general control types include:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSystem-specific controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThese are controls that your system “owns”.\u0026nbsp; If you are running on hardware that you are responsible for, there are system-specific controls for it.\u0026nbsp; If your system is an application, or Major Application, the system-specific controls are those controls that your developers and administrators configure and maintain.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInherited controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIn many cases your system uses components provided by other FISMA systems. In the above example about hardware, what if your system is housed on hardware administered by others? This is not just a possibility – in most cases major applications run within a separate data center. Certainly this is the case for systems housed in the AWS Cloud. In these instances, the data center (or other entity) that houses your system will most likely take care of some of the controls for your system – in which case your system will be able to “inherit” controls.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf the providing system completely takes care of a control, it is called a \u003cstrong\u003ecommon, or fully inherited\u003c/strong\u003e control. If the providing system takes care of part of a control, and relies on your system to take care of the rest of the control, it is called a \u003cstrong\u003ehybrid\u003c/strong\u003e control. (The CFACTS User Manual has additional information on how to inherit a control.)\u003c/p\u003e\u003cp\u003eUnderstanding which controls your team must address and which controls are available through full or partial inheritance will help you understand how to document your security control compliance (which is the next step in the cycle).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSupplemental controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSupplemental controls (previously referred to as non-mandatory controls in ARS 3.1) can be added to a system as necessary, and are not included in baseline control allocation. They should be reviewed and added as appropriate for your system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eImplement security controls\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIt is your responsibility as your system’s security and privacy Subject Matter Expert to make sure that your Business Owner, system developers, and system administrators understand the controls that must be in place for your system to be “secure” to CMS standards.\u0026nbsp; Once these controls have been implemented, \u003cstrong\u003ethey need to be documented within CFACTS\u003c/strong\u003e.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote:\u0026nbsp; All security controls that have been allocated for your system \u003cstrong\u003emust have some comment\u003c/strong\u003e. \u0026nbsp; Even fully inherited controls should have a notation that the control is fully inherited.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDevelop system documentation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eProminent documents are important to understanding the security posture of your FISMA system.\u0026nbsp; CFACTS can help with this process by automatically generating some of the documents, such as the System Security Plan. Other documents are found within CFACTS, such as System Categorization. Others, such as the Information System Risk Assessment (ISRA) must be completed using CMS-approved templates. Finally, others may either use a CMS template or a locally generated document such as the Security Impact Assessment (SIA).\u003c/p\u003e\u003cp\u003eNote:\u003cstrong\u003e Make sure that all CFACTS entries, including all security controls, are accurate and complete at all times.\u0026nbsp;\u003c/strong\u003e This will ensure that CFACTS-generated documents are accurate.\u003c/p\u003e\u003cp\u003eItems for the system documentation include:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSystem Security and Privacy Plan (SSPP)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSSPP\u003c/a\u003e is the key document associated with the FISMA system security. It should provide an accurate, detailed description of the FISMA system itself, security requirements, and those controls that are actually in place to protect the system. This document is generated by CFACTS.\u003c/p\u003e\u003cp\u003eTip: It is a best practice to maintain older copies of SSPPs as new versions are generated. Do not overwrite old SSPPs; you never can tell when you might need to refer to an older version.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eLearn more about System Security and Privacy Plan (SSPP)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInformation System Risk Assessment (ISRA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eISRA\u003c/a\u003e details the business and technical risks associated with a FISMA system.\u0026nbsp; It shares high-level information from CFACTS, as well as specific risks noted and how critical they are.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eLearn more about Information System Risk Assessment (ISRA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrivacy Impact Assessment (PIA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePIA\u003c/a\u003e is not simply a compliance step – it guides the full analysis of a system for privacy risks and controls. A PIA is a process for assessing whether appropriate privacy policies, procedures, business practices, and security controls are implemented to ensure compliance with federal privacy regulations. PIAs are published on HHS.gov and go through a three-year review process.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003eLearn more about Privacy Impact Assessment (PIA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eThird-Party Websites and Applications\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"https://www.osec.doc.gov/opog/privacy/Memorandums/OMB_M-10-23.pdf\"\u003eOffice of Management and Budget Memorandum 10-23\u003c/a\u003e, Guidance for Agency Use of Third-Party Websites and Applications, requires that agencies assess their uses of third-party websites and applications to ensure that the use protects privacy. The mechanism by which agencies perform this assessment is a privacy impact assessment (PIA).\u0026nbsp;\u003c/p\u003e\u003cp\u003eIn accordance with HHS policy, operating divisions (OPDIVs) are responsible for completing and maintaining PIAs for all third-party websites and applications in use. Upon completion of each assessment, agencies are required to make the PIAs publicly available. The CMS Third-Party Websites and Applications (TPWA) Privacy Impact Assessments for each individual OPDIV system can be \u003ca href=\"https://www.hhs.gov/pia/index.html#Third-Party\"\u003eaccessed here on the HHS website\u003c/a\u003e. CMS implementation specifications are included in the CMS Acceptable Risk Safeguards (ARS 5.1).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrivacy Threshold Analysis\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eA Privacy Threshold Analysis (PTA) is a PIA for a system that does not contain PII or only contains HHS employee information. PTAs remain internal to HHS and do not have to go through the three-year review process. A PTA may be updated based on a major change to the system. It is also possible that change to a system could result in a PTA then meeting the threshold to be a PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eConduct Contingency Planning (CP)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://dkanreserve.prod.acquia-sites.com/policy-guidance/risk-management-handbook-chapter-6-contingency-planning-cp\"\u003eContingency Planning\u003c/a\u003e\u0026nbsp;provides instructions, disaster declaration criteria, and procedures to recover information systems and associated services after a disruption. It involves cooperation with your Business Owner, your data center or hosting facility, and senior CMS leadership. (See CMS Risk Management Handbook Chapter 6: Contingency Planning).\u003c/p\u003e\u003cp\u003eAs the ISSO, you will coordinate efforts with your Business Owner to determine the business criticality of key processes. This effort will result in a Business Impact Analysis (BIA) which, in turn, serves as the primary requirement document for determining key recovery metrics including the Recovery Point Objective (RPO), Recovery Time Objective (RTO), Maximum Tolerable Downtime (MTD), and Work Recovery Time (WRT).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe goal is to ensure that there are plans in place to restore business functionality within the Maximum Tolerable Downtime.\u0026nbsp; Note that this may involve restoring the system as originally constructed, moving to alternate processing facilities, or even moving to alternate processing methods.\u0026nbsp;\u003c/p\u003e\u003cp\u003eHere are the key steps and documents involved in Contingency Planning:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCreate Contingency Plan (CP) document\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CP Plan is a single document that contains:\u003c/p\u003e\u003cul\u003e\u003cli\u003eKey recovery metrics for your FISMA system\u003c/li\u003e\u003cli\u003ePre-defined descriptions of conditions that constitute a need for action\u003c/li\u003e\u003cli\u003ePre-defined actions based on the severity of an identified incident\u003c/li\u003e\u003cli\u003eKey staff, contact information, and specific duties for each person\u003c/li\u003e\u003cli\u003eItem-level understanding of all of the hardware and software components of the FISMA system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIt’s important to keep in mind:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CP must be attested to (signed) by the FISMA System Owner annually.\u003c/li\u003e\u003cli\u003eAll of the information necessary for the conducting of a contingency plan must be in the CP.\u0026nbsp; There should be no references to offline personnel lists, contact information, system information, etc.\u0026nbsp;\u003c/li\u003e\u003cli\u003eAll identified Key Personnel must have access to their own copy of the CP in a secure location that is accessible in the event that the FISMA system is unavailable.\u003c/li\u003e\u003cli\u003eThe Contingency Plan, above all FISMA system documentation, must remain current.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eConduct Contingency Plan (CP) Exercise\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CP must be exercised (tested) at least once every 365 days. This is commonly referred to as the “Tabletop Exercise”, but a tabletop exercise is only one (the easiest) way to test the CP. An exercise plan must be prepared and followed during the execution of the test. All staff who participate in an actual CP event must be available for the exercise.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote: \u003cstrong\u003eKey staff members must be trained annually in their contingency responsibilities.\u003c/strong\u003e It is best to perform this training immediately prior to the exercise. Training in this way refreshes individuals’ memories and ensures their availability for the test.\u003c/p\u003e\u003cp\u003e\u003cem\u003eTip: If your FISMA system is involved in an outage that causes you to exercise the CP Plan, you should consider documenting this event as an exercise of your CP Plan.\u003c/em\u003e\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/contingency-plan\"\u003eLearn more about Contingency Plan testing\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eGet after action report\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAfter the exercise is conducted, an after action report must be generated to describe the test and highlight specific deficiencies that must be corrected.\u0026nbsp; These deficiencies may be easily correctable, or may result in POA\u0026amp;Ms.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eAchieve Contingency Plan (CP) re-certification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAfter any corrections have been made, the updated Contingency Plan must be re-certified by the System Owner. Make sure that all key staff members receive updated CP documents that they have access to (\u003cstrong\u003eeven away from the office or after hours\u003c/strong\u003e). Destroy (or return) older copies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAssess security controls for your system(s)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems are required to undergo assessments of risk and security/privacy control compliance before they are given Authorization to Operate (ATO). The assessment and authorization process protects the security and privacy posture of CMS systems throughout the system development lifecycle.\u0026nbsp;\u003c/p\u003e\u003cp\u003eAssessments of risk and/or control compliance are conducted:\u003c/p\u003e\u003cul\u003e\u003cli\u003eWhen a new system is ready to be placed into an operational state\u003c/li\u003e\u003cli\u003eWhen a significant change has been made to an existing system\u003c/li\u003e\u003cli\u003eAnnually, if a system follows a FISMA 1/3 assessment schedule\u003c/li\u003e\u003cli\u003eAd hoc when requested or otherwise required\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCurrently there are two main types of controls assessments – SCA and ACT.\u0026nbsp; Your component will dictate which type of assessment your system undergoes.\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote: Whichever one your system uses, make sure to schedule your assessment \u003cstrong\u003eas soon as possible\u003c/strong\u003e. When the assessment is complete, make sure all documentation is complete and housed in CFACTS appropriately.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity Controls Assessment (SCA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis is a detailed evaluation of the controls protecting an information system.\u0026nbsp; The security controls assessment determines the extent to which controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-controls-assessment-sca\"\u003eLearn more about Security Controls Assessment (SCA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCybersecurity and Risk Assessment Program (CSRAP) (Formally Adaptive Capabilities Testing (ACT))\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCSRAP is a security and risk assessment for FISMA systems at CMS. CSRAP assesses a system's security capabilities to ensure that it operates as intended and meets the security requirements for the information system. CSRAP is a critical component of the \u003ca href=\"https://cybergeek.cms.gov/learn/authorization-operate-ato\"\u003eAuthorization to Operate (ATO)\u003c/a\u003e process and is used to determine the overall system security and privacy posture throughout the system development life cycle (SDLC). For detailed information about CSRAP, see \u003ca href=\"https://confluenceent.cms.gov/download/attachments/214794255/CSRAP%20Assessment%20Handbook%20v3.1.pdf?version=1\u0026amp;modificationDate=1711993052415\u0026amp;api=v2\"\u003eCybersecurity and Risk Assessment Program Handbook\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePenetration testing\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePenetration testing is performed on information systems or individual system components to identify vulnerabilities that could be exploited by bad actors. It is used to validate vulnerabilities or determine the degree of resistance that organizational information systems have to risk within a set of specified constraints (e.g., time, resources, and/or skills).\u0026nbsp;\u003c/p\u003e\u003cp\u003ePenetration testing attempts to duplicate the actions of internal and external bad actors in carrying out hostile cyber-attacks against the organization and allows a more in-depth analysis. It can be conducted on the hardware, software, or firmware components of an information system and can exercise both physical and technical security controls.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePenetration testing is performed on all High Value Assets (HVA) information systems within CMS at a frequency of every 365 days or when there has been a significant change to the system.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIt is considered to be part of the group of assessments required for CMS systems, and its results are recorded in CFACTS similarly to the controls assessments (SCA and/or ACT).\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/penetration-testing\"\u003eLearn more about penetration testing\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity Assessment Report (SAR) and CAAT file\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eFor all assessments, a final Security Assessment Report (SAR) chronicles the results of the assessment. The \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eRisk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization\u003c/a\u003e states:\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cem\u003eAt the completion of a security controls assessment, the independent assessor completes a CMS Assessment and Audit Tracking (CAAT) spreadsheet. The CAAT spreadsheet is utilized for all CMS audits, assessments and penetration testing vulnerabilities. The completed CAAT spreadsheet is emailed to the CMS CISO mailbox at \u003c/em\u003e\u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003e\u003cem\u003eCISO@cms.hhs.gov\u003c/em\u003e\u003c/a\u003e\u003cem\u003e for upload into the CFACTS tool. Once uploaded into CFACTS, the weaknesses are automatically generated for all items with a status of “other than satisfied”. The ISSO for the associated information system receives an automated email notification from the CFACTS tool identifying a new weakness. The ISSO has 30 days to create a POA\u0026amp;M within CFACTS.\u003c/em\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManage Plan of Action and Milestones (POA\u0026amp;M)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe POA\u0026amp;M is a remedial action plan (the process of accepting or resolving a risk) which helps the agency to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIdentify and assess information system security and privacy weaknesses\u003c/li\u003e\u003cli\u003eSet priorities about how to mitigate weaknesses using available resources\u003c/li\u003e\u003cli\u003eMonitor and report progress toward mitigating the weaknesses\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eYou – as the ISSO – are responsible for opening, maintaining / updating, and closing POA\u0026amp;Ms on a continual basis to ensure the maximum level of information security for system(s) entrusted to your care.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/plan-action-and-milestones-poam\"\u003eLearn more about Plan of Action \u0026amp; Milestones (POA\u0026amp;M)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthorize the system\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eSystem authorization is the formal decision by senior officials to allow a CMS information system to operate. Commonly known as Authorization to Operate (ATO), this is the culmination of all the tests, assessments, remediation, documentation, and other activities that the ISSO and others on the portfolio team have done to ensure information security for the system.\u003c/p\u003e\u003cp\u003eIn formal terms, authorization is described in the CMS Risk Management Handbook Chapter 4: Security Assessment and Authorization:\u003c/p\u003e\u003cp\u003e\u003cem\u003eSecurity authorizations are official management decisions that are conveyed through authorization decision documents by senior organizational officials or executives (i.e., authorizing officials) to authorize operation of information systems to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon security controls. The CIO serves as the authorizing official for CMS. The CIO is responsible for making an overall determination of risk and authorizing CMS information systems for operation, if it is determined that the associated risks are acceptable. An ATO memo is signed by the CIO giving the System Owner/BO formal authority to operate a CMS information system.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThere are three NIST document requirements for an ATO “package” and six more that are specific to CMS.\u0026nbsp; The documents include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eSystem Security and Privacy Plan (SSPP)\u003c/li\u003e\u003cli\u003eSecurity Assessment (Final) Report (SAR)\u003c/li\u003e\u003cli\u003ePlans of Action and Milestones (POA\u0026amp;M)\u003c/li\u003e\u003cli\u003eContingency Plan (CP)\u003c/li\u003e\u003cli\u003eCP Testing Plan\u003c/li\u003e\u003cli\u003eCP Test After Action Report\u003c/li\u003e\u003cli\u003eInformation System Risk Assessment (ISRA)\u003c/li\u003e\u003cli\u003ePrivacy Impact Assessment (PIA)\u003c/li\u003e\u003cli\u003eInterconnection Security Agreement (ISA) – as applicable\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eGetting these documents together and conducting all necessary steps can be a long process – so \u003cstrong\u003eyou should start working on your ATO as early as possible\u003c/strong\u003e to ensure timely completion.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/authorization-operate-ato\"\u003eLearn more about System Authorization\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eContinuous monitoring\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eContinuous monitoring is the practice of using modern tools and technology to continuously check systems for vulnerabilities and risks. Rather than thinking of getting an ATO as having “achieved” compliance, continuous monitoring allows us to observe and track evolving risks over time. Security is never “done”.\u003c/p\u003e\u003cp\u003eContinuous monitoring is a growing program at CMS. As an ISSO, you will work closely with the CMS Cybersecurity Integration Center (CCIC) to ensure that your system is appropriately monitored.\u0026nbsp; CCIC ensures oversight of information security and privacy, including Security Information Event Management, for each FISMA system operating by or on behalf of CMS.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe CCIC delivers various agency-wide security services.\u0026nbsp; These services include \u003ca href=\"/learn/continuous-diagnostics-and-mitigation-cdm\"\u003eContinuous Diagnostics and Mitigation (CDM)\u003c/a\u003e as well as security engineering, incident management, forensics and malware analysis, information sharing, cyber threat intelligence, penetration testing, and software assurance.\u003c/p\u003e\u003cp\u003eMore information about continuous monitoring can be found in the \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eCMS Risk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManage security incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAlong the way, a system entrusted to your care might have a security or privacy incident or breach. Anytime there is a violation of computer security policies, acceptable use policies, or standard security practices at CMS, it is considered an\u003cstrong\u003e incident\u003c/strong\u003e. If an incident involves the loss of control or unauthorized disclosure of Personally Identifiable Information (PII), then the incident is considered a \u003cstrong\u003ebreach\u003c/strong\u003e.\u003c/p\u003e\u003cp\u003eKnown or suspected security or privacy incidents involving CMS information or information systems \u003cstrong\u003emust be reported immediately\u003c/strong\u003e to the CMS IT Service Desk:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePhone: 410-786-2580 or 1-800-562-1963\u003c/li\u003e\u003cli\u003eEmail: \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e.\u0026nbsp;\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eYou as the ISSO should be apprised of the situation as soon as possible (if you’re not the one who initially reported the incident). You will work with the Incident Management Team (IMT) and others involved with your system to manage and report the incident and mitigate any resulting harm. More details can be found in the CMS Risk Management Handbook (RMH) Chapter 8: Incident Response.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eISSO toolkit\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis section contains links to documents you will access often in your daily activities, and resources to support your work as an ISSO. You should become familiar with the purpose and usage of each.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDocuments\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCMS Acceptable Risk Safeguards (ARS 5.1)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Information Security Acceptable Risk Safeguards (ARS 5.1) defines information security and privacy control requirements and includes additional, detailed policy traceability statements within each control description. The ARS 5.1 provides guidance on customizing (tailoring) controls and enhancements for specific types of missions/business functions, technologies, or environments of operation. Users of the ARS 5.1 may tailor specific mandatory controls as well as most of the non-mandatory and unselected controls.\u003c/p\u003e\u003cp\u003eThe goal of the ARS 5.1 is to define a baseline of minimum information security and privacy assurance controls. The controls are based on both internal CMS governance documents and laws, regulations, and other authorities created by institutions external to CMS. Protecting and ensuring the confidentiality, integrity, and availability for all of CMS’ information and information systems is the primary purpose of the information security and privacy assurance program. The ARS 5.1 complies with the CMS IS2P2 by providing a defense-in-depth security structure along with a least-privilege, need-to-know basis for all information access.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cybergeek.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eLearn more about ARS 5.1\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Information Security and Privacy Policy (IS2P2)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis policy defines the framework under which CMS protects and controls access to CMS information and information systems. It provides direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems; systems maintained on behalf of CMS; and other collections of information to assure the confidentiality, integrity, and availability of CMS information and systems.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eAlong with the Acceptable Risk Safeguards (ARS 5.1), the IS2P2 stands as one of the core reference sources for cybersecurity policies and practices at CMS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eGo to the IS2P2\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Risk Management Handbooks\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis series of handbooks is designed to help ISSOs understand and address the many CMS security and privacy requirements developed to protect their system(s). The RMH chapters are generally aligned to provide specific guidance and recommendations for specific ARS 5.1 Control Families. (For example, \u003cstrong\u003eRMH Chapter 6: Contingency Planning\u003c/strong\u003e addresses the ARS 5.1 controls in the \u003cstrong\u003eCP Family\u003c/strong\u003e.) As you work through your ARS 5.1 controls, you should have the appropriate RMH handy.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\"\u003eLearn more about the CMS Risk Management Handbook (RMH)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTools and resources\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCFACTS\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS FISMA Controls Tracking System (CFACTS) is the system used by CMS as a repository for managing the security and privacy requirements of its information systems. It provides a common foundation to manage policies, controls, risks, assessments, and deficiencies across the CMS enterprise. You will use it for tracking your tasks associated with system authorization, risk remediation, and more.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cfacts3.cms.cmsnet/apps/ArcherApp/Home.aspx#home\"\u003eGo to CFACTS\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003cp\u003eA user manual is produced by the team that administers CFACTS and gives a guided tour through all activities in CFACTS. Although it is not a primer in risk management, many activities and concepts can be understood implicitly through their description in the User Manual and implementation in CFACTS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cfacts3.cms.cmsnet/apps/ArcherApp/Home.aspx\"\u003eGo to CFACTS user manual\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISPG website (CyberGeek)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe Information Security and Privacy Group (ISPG) provides the “CyberGeek” website as a one-stop shop for all security and privacy related information at CMS – including dedicated resource pages for ISSOs and other roles. This is a new site, and more information will become available as it grows.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://security.cms.gov/\"\u003eGo to ISPG website (CyberGeek)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Slack\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSlack is an application that allows for fast and easy communication among all CMS employees and contractors. Spaces called channels allow for focused communication which will keep you organized and informed during your daily routine. Below is a list of Slack channels that will help you on your journey to becoming a fully independent ISSO:\u003c/p\u003e\u003cul\u003e\u003cli\u003e#ars-feedback\u003c/li\u003e\u003cli\u003e#cfacts_community\u003c/li\u003e\u003cli\u003e#cisab\u003c/li\u003e\u003cli\u003e#cms-isso\u003c/li\u003e\u003cli\u003e#cyber-risk-management\u003c/li\u003e\u003cli\u003e#ispg-all\u003c/li\u003e\u003cli\u003e#isso-as-a-service\u003c/li\u003e\u003cli\u003e#security_community\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAcronyms\u003c/h4\u003e\u003cp\u003eLike most other parts of government, the security and privacy world at CMS is full of acronyms. ISPG maintains a list of acronyms so you can easily look up unfamiliar terms.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/acronyms\"\u003eSee the acronym list here\u003c/a\u003e.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Framework\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAs an ISSO, your daily tasks support CMS in applying the NIST Cybersecurity Framework (CSF), guidance created by the National Institute of Standards and Technology to help organizations effectively manage cybersecurity risk. (Executive Order 13800, \u003ca href=\"https://www.federalregister.gov/documents/2017/05/16/2017-10004/strengthening-the-cybersecurity-of-federal-networks-and-critical-infrastructure\"\u003eStrengthening the Cybersecurity of Federal Networks and Critical Infrastructure\u003c/a\u003e, made the Framework mandatory for U.S. federal government agencies.)\u003c/p\u003e\u003cp\u003eWe have created the \u003cstrong\u003eISSO Framework\u003c/strong\u003e to show how ISSO responsibilities align with specific functions and categories of the NIST Cybersecurity Framework, and how the ISSO works with other people within the organization to complete tasks. You can refer to this Framework whenever you have questions about documentation or activities related to your job.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://share.cms.gov/Office/OIT/ISPG/DSPC/ISPG%20DSPC%20Documents%20%20Internal/ISSO%20Engagement%20and%20Outreach%20Initiative/ISSO%20Framework\"\u003eGo to the ISSO Framework\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity and Privacy Language for IT Procurements\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS provides templated language to use in IT procurements to ensure the security and privacy of information and information systems that CMS uses. This includes systems provided or managed by contractors or subcontractors on behalf of CMS. The ISSO may provide support to this process.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-and-privacy-requirements-it-procurements\"\u003eLearn more about Security and Privacy Language for IT Procurements\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eTarget Life Cycle (TLC)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS requires all new IT systems to follow the Target Life Cycle (TLC), a common framework for governing system development across the enterprise. The TLC accommodates various IT development methodologies while ensuring that systems meet all applicable legislative and policy requirements.\u0026nbsp;\u003c/p\u003e\u003cp\u003e(The TLC has replaced the former Expedited Life Cycle (XLC) as the official IT governance framework at CMS. If your current projects or contracts specify the use of XLC-related tools, templates, or reviews, you may continue using them.\u0026nbsp; You may also use fewer or alternative tools and templates, as long as you meet the minimum requirements outlined within the TLC.)\u003c/p\u003e\u003cp\u003eAs an ISSO, you will enter the TLC by filling out an intake form when:\u003c/p\u003e\u003cul\u003e\u003cli\u003eInitiate a new IT project\u003c/li\u003e\u003cli\u003eConduct an acquisition to support a new IT project\u003c/li\u003e\u003cli\u003eRequest new/increased funding to support an IT project\u0026nbsp;\u003c/li\u003e\u003cli\u003ePlan significant changes to an existing IT project\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAfter submitting your form, the CMS IT Governance Team will help you meet TLC requirements. You can also contact the governance team via email: \u003ca href=\"mailto:IT_Governance@cms.hhs.gov\"\u003eIT_Governance@cms.hhs.gov\u003c/a\u003e\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/TLC\"\u003eLearn more about the TLC\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://share.cms.gov/Office/OIT/CIOCorner/Lists/Intake/NewForm.aspx\"\u003eFill out an intake form\u003c/a\u003e (requires CMS login)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eResources external to CMS\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eHHS Policy for Information Security and Privacy Protection (IS2P)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe Department of Health and Human Services (HHS) is the parent organization for CMS. All of our policies and guidance are based on HHS-level documentation. The IS2P comprises HHS policies and procedures that ensure the secure collection, use, sharing, and storage of information that is both terrorism-related information and “protected information (PI)”.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWhere possible, this document identifies existing HHS policies and procedures that meet the privacy requirements. Where necessary, however, this document also creates policies specific to the activities and resources that HHS requires.\u0026nbsp; The IS2P is one of the base documents from which CMS requirements are created. You can request a copy of this policy from the CISO team: \u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003eCISO@cms.hhs.gov\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eHHS Cybersecurity Library\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSometimes CMS borrows policies and standards directly from HHS, our parent organization. You will sometimes need to access the HHS library of cybersecurity documents for your work.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://intranet.hhs.gov/security/index.html\"\u003eGo to the HHS library\u003c/a\u003e (requires login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNIST Special Publications\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eNIST Special Publications in the 800 series are of general interest to the computer security community, and these documents serve as the foundation for CMS security and privacy practices. Specifically helpful to ISSOs are the publications that contain detailed explanations of information security controls and the test cases used to assess them.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53: Recommended Security Controls for Federal Information Systems\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final\"\u003eNIST SP 800-53A: Guide for Assessing the Security Controls in Federal Information Systems\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-800-series-of-special-publications\"\u003eLearn more about NIST SP 800 series\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNIST Computer Security Resource Center\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe National Institute of Standards and Technology (NIST) publishes helpful resources on computer, cyber, and information security and privacy. Explore publications, news, programs, and events that will help you expand your cybersecurity knowledge.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/\"\u003eVisit the NIST Resource Center\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eOMB Memoranda and Circulars\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eEvery year, the Office of Management and Budget (OMB) publishes a Memo with reporting instructions and guidance for FISMA, which can be useful to people with cybersecurity responsibilities at CMS. \u003ca href=\"https://www.whitehouse.gov/omb/information-for-agencies/memoranda/\"\u003eExplore OMB memos here\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eThere are a number of OMB Circulars that provide general guidance on information security. Three of the most relevant are:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/omb/circulars_a130_a130appendix_iii\"\u003eA-130 - Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.osec.doc.gov/opog/privacy/Memorandums/OMB_Circular_A-123.pdf\"\u003eA-123 - Management's Responsibility for Internal Control\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/omb/circulars_a127/\"\u003eA-127 - Financial Management Systems\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eOMB A-130 applies to all IT systems while A-123 and A-127 apply primarily to financial systems. ISSOs should be aware of these foundation documents and have a general understanding of their content. \u003ca href=\"https://www.whitehouse.gov/omb/information-for-agencies/circulars/\"\u003eExplore all OMB Circulars here\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho to contact\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWhen you have a question or challenge, we are here to help! Here are key points of contact for situations you may face as an ISSO.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity or privacy incident\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eReport known or suspected security or privacy incidents involving CMS data to the CMS IT Service Desk by calling 410-786-2580 or 1-800-562-1963 or via e-mail to \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity or privacy questions\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eDo you have a question or concern related to CMS information security or privacy, and need a place to start? Send an email to the CISO Team at \u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003eCISO@cms.hhs.gov\u003c/a\u003e regarding information security, or an email to \u003ca href=\"mailto:Privacy@cms.hhs.gov\"\u003eprivacy@cms.hhs.gov\u003c/a\u003e for questions regarding information privacy.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eISSO questions\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eIf you have questions about the ISSO role or other activities such as the ISSO Forum —or if you just want to hear from an ISSO — send an email to \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eOversight and guidance\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Cyber Risk Advisor (CRA) and Privacy Advisor are your ISPG support representatives. They help improve accountability and risk management by providing hands-on oversight to system cybersecurity and privacy risk.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eISSO community\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCMS Cybersecurity Community Forum (C3F)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis monthly meeting is held for the benefit of the CMS security community, covering timely and relevant topics from ISPG speakers. It’s open to all CMS and contractor security professionals. Meeting details (location, time, video conferencing link) will be in the email invitation, which is sent monthly to everyone at CMS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://confluenceent.cms.gov/pages/viewpage.action?spaceKey=IIP\u0026amp;title=CMS+ISSO+Forum\"\u003eSee past Forum videos and materials\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Journal\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eRead the ISSO Journal to stay updated on cybersecurity trends, learn about current events, and hear from other ISSOs. The Journal is distributed widely among CMS staff, and all cybersecurity professionals – both CMS and contractor staff – are invited to contribute! Contact us by email (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e) if you would like to write a post.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://confluenceent.cms.gov/pages/viewpage.action?spaceKey=IIP\u0026amp;title=CMS+ISSO+Journal\"\u003eRead the ISSO Journal\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Mentorship Program\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe mentorship program allows experienced ISSOs to support those who are newer to the role. For mentors, this is an opportunity to build leadership skills and strengthen the future of cybersecurity at CMS. For mentees, this allows you to build your knowledge faster and get hands-on support. The structure of the program is flexible — both ISSOs will decide what cadence and duration for meetings works for them.\u0026nbsp;\u003c/p\u003e\u003cp\u003eA mentorship usually lasts 6 months to a year. Your supervisor will need to approve your participation in the program.\u0026nbsp; Note that although the program is generally used by newer ISSOs, it is also available for existing ISSOs who want additional bootstrap help – for example, if they are dealing with an issue or project that is new to them. Mentorship is for these ISSOs, too!\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/isso-mentorship-program\"\u003eLearn about the ISSO Mentorship Program\u003c/a\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eTraining\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePeople come to the ISSO role from many backgrounds, with differing experiences, so each may start at a different place. Broadly, ISSOs need to have both general cybersecurity knowledge and specific knowledge of how things operate at CMS. For new ISSOs, see the “Getting Started” section of this Handbook for tips on beginning your training journey.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNICE code for ISSOs\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere is a Federal initiative to help train cybersecurity professionals. The \u003ca href=\"https://www.nist.gov/itl/applied-cybersecurity/nice\"\u003eNational Initiative for Cybersecurity Education\u003c/a\u003e (NICE) seeks to link appropriate training to cybersecurity roles by associating NICE “codes” with training opportunities. \u003cstrong\u003eAs an ISSO, your NICE code is OV‐MGT‐001\u003c/strong\u003e. Knowing this will help you find appropriate training for particular tasks or knowledge areas.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTraining sources\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere are many external sources – such as professional associations and training organizations – that can help you expand your cybersecurity knowledge and skills, but you can also get excellent free training that is provided by CMS and HHS. They are offered via the following platforms:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"http://www.cms.gov/cbt\"\u003eCMS Computer Based Training\u003c/a\u003e (CBT) - Free online training courses provided by CMS\u003c/li\u003e\u003cli\u003eCMS Cybersecurity Training Catalog - List of current training offerings and events (such as webinars) from CMS\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://confluenceent.cms.gov/display/IIP/ISSO+Training\"\u003eISSO Training Page\u003c/a\u003e - Collection of training resources in the ISPG Confluence environment that helps you navigate the training options available to you\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://ams.hhs.gov/amsLogin/SimpleLogin.jsp\"\u003eHHS Learning Management System\u003c/a\u003e\u0026nbsp; (LMS) - Free courses for federal employees (not contractors) provided through HHS to advance your core cybersecurity knowledge or prepare you for certifications\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://fedvte.usalearning.gov/\"\u003eFederal Virtual Training Environment\u003c/a\u003e (FedVTE) - Another source of free training courses available to federal employees and contractors (similar to the LMS above).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eTo help ISSOs focus on the most relevant training, below is a list of Basic, Intermediate, and Advanced courses that will help you grow in the specific skills needed for your role.\u003c/p\u003e\u003ch4\u003eBasic ISSO training\u003c/h4\u003e\u003cp\u003eThe courses recommended below provide both an introduction to cybersecurity in general and guidance on how these concepts are implemented at CMS. The courses listed in bold are the most important. You should consider some or all of the rest of the courses as your time permits. If possible, try to complete the bolded courses within your first two months as an ISSO. There is no cost to take these courses. Note: HHS LMS is only available to federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eISSO Fundamentals\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWorking With CFACTS\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eClassroom / Remote\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eAll About the CMS Acceptable Risk Safeguards (ARS 5.1)\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePrivacy and Awareness Training\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eExecutive’s Guide to Security: Protecting Your Information\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Awareness: Getting Started with Security Foundations, Information Security Fundamentals, and Key Security Terms\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompliance Expert: IT Security - Phishing, Safeguarding Mobile Devices, and Privacy \u0026amp; Information Security (The Basics)\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity 101: Auditing \u0026amp; Incident Response and Session \u0026amp; Risk Management\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003eIntermediate ISSO training\u003c/h4\u003e\u003cp\u003eThe courses recommended below will build on your initial knowledge. As before, you should start with the courses listed in bold, or on topics that have immediate importance to you. There is no cost to take these courses. Note: HHS LMS is only available for federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eNavigating New Cybersecurity and Privacy Policies and Procedures\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eHow Hackers Hack and How to Protect Yourself\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eIncident Response at CMS\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCMS Privacy Incident Response: Quick Guide for Business Owners\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Race\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eFundamentals of Cyber Risk Management\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFoundations of Incident Management\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompliance Expert: IT Security - Phishing\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Audits\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eImplementation of Security Controls\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003eAdvanced ISSO training\u003c/h4\u003e\u003cp\u003eThe advanced courses recommended below will help you gain a deeper understanding of the cybersecurity issues that you have been working with. They may also be appropriate to take earlier if you entered the ISSO role with a good basic understanding of both CMS operations and cybersecurity in general. There is no cost to take these courses.\u0026nbsp; Note: HHS LMS is only available for federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eEmerging Cyber Security Threats\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecuring Infrastructure Devices\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecuring the Network Perimeter\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Computing Fundamentals: Cloud Security\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Architecture\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Security\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Platforms\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCloud Security Fundamentals\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA A+: Security Fundamentals\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eEncryption and Malware\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA Server+: Network Security Protocols\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA Cloud+\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e"])</script><script>self.__next_f.push([1,"27:T12321,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook gives practical guidance to Information System Security Officers (ISSO)s at CMS when performing their necessary tasks.\u0026nbsp; It helps new ISSOs get started and explains the responsibilities, resources, and organizational relationships needed for an ISSO to be successful.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis guide is for CMS (Federal) ISSOs, Contractor ISSOs, and contract security support individuals.\u0026nbsp; Business Owners and their staff may also find parts of this handbook useful, particularly when appointing new ISSOs or gaining a better understanding of ISSO tasks.\u003c/p\u003e\u003cp\u003eThe ISSO role is critical to the safe and authorized use of sensitive information in support of CMS’ commitment to improving healthcare for millions of Americans. As an ISSO,\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat do ISSOs do?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eEvery CMS system must formally designate an ISSO who serves as the primary point of contact responsible for the system’s security and privacy.\u0026nbsp;\u003c/p\u003e\u003cp\u003eISSOs at CMS are responsible for overseeing the security and privacy posture of the system(s) entrusted to their care, coordinating all information system risk management and information privacy activities, and acting as the Business Owner’s “go-to person” for security questions and needs. Together, the ISSOs make up a supportive community working to ensure the success of the cybersecurity program at CMS.\u003c/p\u003e\u003cp\u003eFor more details, see the section on role and responsibilities.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho do ISSOs work with?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO is part of the\u003cstrong\u003e portfolio team\u003c/strong\u003e – the group of people who work together to make sure that any given CMS information system complies with federal security requirements and is managed in a way that protects the personal and health information of those who depend on CMS for benefits. The portfolio team has the following roles:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProgram Executive, Information System Owner (ISO), Business Owner (BO), and Information System Security Officer (ISSO)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThese people work together to take full responsibility for implementing the required security and privacy controls and managing the cybersecurity and privacy risk posture for each system. All of these roles must be an agency official (federal government employee) except the ISSO, which may be a federal employee or a contractor.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCyber Risk Advisor (CRA)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eCRAs are the “go-to” experts in all areas of risk management, and as such they evaluate and communicate the risk posture of each FISMA system to executive leadership and make risk-based recommendations to the Authorizing Official. CRAs also help to identify the types of information processed by a system, assign the appropriate security categorizations, determine the privacy impacts, and manage information security and privacy risk. They facilitate the completion of all federal cybersecurity and privacy requirements – and this means that CRAs and ISSOs often work closely together.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eData Guardian\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Data Guardian coordinates CMS Program activities involving beneficiary and other types of consumer information that require privacy protections.\u0026nbsp; The Data Guardian must be an agency official (federal government employee) and must fulfill shared responsibilities with the CMS Business Owner.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePrivacy Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Privacy Advisor is a member of ISPG who provides privacy-related expertise to help the team identify and manage privacy risk.\u0026nbsp; The Privacy Advisor is an agency official (federal government employee) and serves as a point of contact for issues related to the Privacy Act. They also support the completion of privacy-related artifacts such as Systems of Records Notice (SORN), Privacy Act reviews, and FISMA and Privacy Management Report.\u003c/p\u003e\u003cp\u003eDetailed information about all of these roles can be found in the CMS Information Security and Privacy Policy (IS2P2) and the HHS Policy for Information Security and Privacy Protection (IS2P).\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat should an ISSO know?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe goal of every ISSO should be to support the BO to securely provide the service intended by the system. To help accomplish this goal, an ISSO should ideally know and understand their component’s business processes and how the system supports that business. This knowledge is critically applied during the construction of the System Security and Privacy Plan (SSPP).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eInformation security is a means to an end and not the end in itself\u003c/strong\u003e. In the public sector, information security is secondary to the agency's services provided to its constituency. We, as security professionals, must not lose sight of these goals and objectives.\u003c/p\u003e\u003cp\u003eIn order to help the BO provide a CMS service in a manner that is demonstrably secure and safeguards any sensitive beneficiary information, the ISSO must know (at a minimum):\u003c/p\u003e\u003cul\u003e\u003cli\u003eMission and business functions of their component\u003c/li\u003e\u003cli\u003eHow the system supports the component’s mission\u003c/li\u003e\u003cli\u003eSystem details, including:\u003cul\u003e\u003cli\u003eArchitecture\u003c/li\u003e\u003cli\u003eSystem components (hardware, software, peripherals, etc.)\u003c/li\u003e\u003cli\u003eLocation of each system component\u003c/li\u003e\u003cli\u003eData flow\u003c/li\u003e\u003cli\u003eInterconnections (internal and external)\u003c/li\u003e\u003cli\u003eSecurity categorization\u0026nbsp;\u003c/li\u003e\u003cli\u003eSecurity requirements\u003c/li\u003e\u003cli\u003eConfiguration management processes and procedures\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eUsers (how many, location, role, etc.)\u003c/li\u003e\u003cli\u003eKey personnel by name\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eHow are ISSOs appointed?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CMS Program Executive in coordination with the Data Guardian, ISO, and Business Owner, is responsible for nominating appropriately qualified ISSO appointees, as defined under FISMA, to the CISO for approval.\u003c/p\u003e\u003cp\u003eThe nominated ISSO, by signing the appointment letter, agrees to maintain the appropriate operational security posture of the information system by fulfilling all of the responsibilities identified in the \u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS Information Security and Privacy Policy (IS2P2)\u003c/a\u003e and the HHS Policy for Information Security and Privacy Protection (IS2P).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eA subset of the ISSO’s duties and responsibilities is contained in the \u003ca href=\"/learn/isso-appointment-letter\"\u003eappointment letter\u003c/a\u003e. ISSO letters must be updated whenever a change occurs. The designated ISSO should be consistently identified in three sources: the ISSO letter, the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e, and in \u003ca href=\"/learn/cms-fisma-continuous-tracking-system-cfacts\"\u003eCFACTS\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe signed appointment letter should be given to the appropriate CRA for further action.\u0026nbsp;\u003cstrong\u003e It is the responsibility of the CRA to upload the letter to CFACTS\u003c/strong\u003e.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eGetting started (for new ISSOs)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCongratulations on your new assignment as an Information System Security Officer (ISSO) at CMS! Because you are charged with protecting the sensitive information contained in systems that support healthcare delivery for millions of people, your role is vital to the success of CMS’ mission. You will learn how to identify and protect information that includes:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePersonally Identifiable Information (PII)\u003c/li\u003e\u003cli\u003eIndividually Identifiable Information (IIF)\u003c/li\u003e\u003cli\u003eProtected Health Information (PHI)\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis means that security must become a vital part of your daily routine and always top-of-mind. Your training as an ISSO will ensure that you know and understand the requirements for protecting government assets like classified information, property, and personnel.\u003c/p\u003e\u003cp\u003eMost importantly, you will learn to work as part of a team that is dedicated to making sure CMS information systems can operate securely. While CMS has established a security program to protect assets and keep sensitive information safe, the key ingredient is always \u003cstrong\u003epeople\u003c/strong\u003e. No matter how comprehensive a program may be, you and your coworkers will ultimately determine the success of our established procedures.\u0026nbsp;\u003c/p\u003e\u003cp\u003eAnd we are here to help you along the way! This Handbook is your primary resource for initial information about your role, and will direct you to other sources of help and support.\u003c/p\u003e\u003cp\u003eHere are the steps you should take to get started:\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eComplete the paperwork\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIf you have not already, make sure that your \u003ca href=\"/learn/isso-appointment-letter\"\u003e\u003cstrong\u003eISSO Appointment Letter\u003c/strong\u003e\u003c/a\u003e is completed and submitted to your Cyber Risk Advisor (CRA) by your Business Owner (BO). The Appointment Letter is intended to formally nominate you as an ISSO. It also gives you a wealth of information about your duties and responsibilities. It also contains the qualifications and training to which you should aspire. This document may be your first communication with your CRA — the first of many conversations.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf you need a copy of the ISSO Appointment Letter template, contact the ISSO Support Team: \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eComplete ISSO onboarding\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO Support team in ISPG can help get you started. You should ask for an initial meeting with the team to orient you to your new role and next steps. \u0026nbsp; You should also reach out to your CRA, who may wish to meet on a regular basis initially, especially if your system has an important near-term milestone. If your BO did not set this up for you, you can do it yourself by sending a note to \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e. It is helpful to put the word “Onboarding” in the subject line.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKnow your systems\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eMake sure that in your conversation with your Business Owner, you understand whether you are going to be the primary ISSO (or the only ISSO), or if you are going to be an assistant. Do you know where your system is located? When does the Authority to Operate (ATO) expire? Are you working on a new system? The more you know at the beginning, the easier it will be to prioritize and to work with your integrated team. If you have questions about any of this, reach out to the ISSO Support Team (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMeet your team\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIn addition to your BO and your CRA, there are others that you should get to know. We recommend that you reach out to them. We also recommend face to face meetings, at least initially. Some others you should get to know include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eOther ISSOs in your component, if applicable\u003c/li\u003e\u003cli\u003eYour system’s Technical Lead\u003c/li\u003e\u003cli\u003eWhen appropriate, your system’s contractor security support\u003c/li\u003e\u003cli\u003eThe ISSO Support Team (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAssess your skills with the ISSO Score Card\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eISSOs come from many backgrounds, both technical and non-technical. Even new ISSOs with a technical background may not be familiar with the “CMS way” of operating. While you will be busy with your new role, you should take some initial time to get a better awareness of your capabilities to be a CMS ISSO through some focused initial training.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWe’ve made it easy to figure out what training you should prioritize using a self-assessment tool: the \u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eISSO Score Card.\u003c/a\u003e Every ISSO is encouraged to take this assessment regularly as their knowledge expands. The ISSO Score Card is:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eConfidential\u003c/strong\u003e - only you will see the results\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eQuick\u003c/strong\u003e - only taking 10-15 minutes to complete\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eGeared to ISSO duties\u003c/strong\u003e - taken directly from CMS policies and requirements\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePersonalized\u003c/strong\u003e - you’ll get a customized report to help you make a training plan\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eEasy\u003c/strong\u003e - using a simple online web interface\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eGo to the ISSO Score Card\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eSign up for training\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAs an ISSO, it is vital that you understand security and privacy fundamentals and how they are applied at CMS. Regardless of your prior level of experience, you will need to know the CMS-specific workflows and governance. There is a wealth of training available to you, both for getting started and deepening your knowledge.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eWondering where to start\u003c/strong\u003e? Here’s a simple checklist to make sure you complete the essential training that will start you on the road to success:\u003c/p\u003e\u003cul\u003e\u003cli\u003eFigure out what you need to know (or brush up on) using the \u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eISSO Score Card\u003c/a\u003e. Use the results to sign up for training that is customized to your level.\u003c/li\u003e\u003cli\u003eLearn about 6 key job functions of ISSOs using the \u003ca href=\"https://www.cms.gov/cbt/login/default.aspx\"\u003evideo training series from CMS\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eSign up for CFACTS training – it’s worth the 2-day time investment to get a solid grasp on this essential tool for the ISSO’s daily work. (This is available in the CMS Computer Based Training platform).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFinally, to build upon the checklist above, we have provided a list of Basic, Intermediate, and Advanced ISSO training courses that are free for you to take. See the Training section of this Handbook for details.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eGet a mentor\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOptionally, you can join the \u003ca href=\"/learn/isso-mentorship-program\"\u003e\u003cstrong\u003eISSO Mentorship Program\u003c/strong\u003e\u003c/a\u003e to be paired with an experienced ISSO. Once paired, you should work together to develop a cadence for meeting and knowledge sharing. This allows you to gain confidence faster and get hands-on support. Learn more about the ISSO Mentorship Program here.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eJoin the community\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe cybersecurity community at CMS is alive and growing. There are all kinds of ways that you can get involved, get an idea of what’s going on at CMS, and learn how it affects you. Attend the CMS Cybersecurity Community Forum, read the ISSO Journal, and look for ISPG-sponsored security and privacy activities.\u003c/p\u003e\u003cp\u003eFinally, if you have any questions along the way, just ask. Your job is very important to the success of CMS programs, and everyone at ISPG is here to support you!\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eGoals for your first year\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eBy the end of your first year as an ISSO, it should be your goal to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eLearn the security planning and administrative security procedures for systems that process sensitive information such as PHI, PII, FTI, and classified and national intelligence data\u003c/li\u003e\u003cli\u003eUnderstand the implementation and enforcement of CMS’ Information System Security and Privacy policies and practices\u0026nbsp;\u003c/li\u003e\u003cli\u003eKnow the concerns and requirements that determine the administration and management of physical, system, and data access controls based on the sensitivity of the data processed and the corresponding authorization requirements\u003c/li\u003e\u003cli\u003eLearn the identification, analysis, assessment and evaluation of information system threats and vulnerabilities and their impact on their component’s critical information infrastructures\u003c/li\u003e\u003cli\u003eBe able to identify management, technical, personnel, operational and physical security controls\u003c/li\u003e\u003cli\u003eUnderstand any additional critical areas of knowledge related to your system\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eRole and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eISSOs maintain a strong security and privacy posture for their assigned system(s) in the following high-level ways:\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eServe as principal advisor\u003c/strong\u003e to the System Owner (SO), Business Owner (BO), and the Chief Information Security Officer (CISO) on all system security and privacy matters\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMaintain system authorization \u003c/strong\u003eby following the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-risk-management-framework-rmf\"\u003eNIST Risk Management Framework\u003c/a\u003e to select, implement, document, test, and maintain the security and privacy controls required to authorize and operate information systems within CMS’s risk tolerance throughout the \u003ca href=\"https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/tlc\"\u003eTarget Life Cycle\u003c/a\u003e (TLC)\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMaintain security and privacy operations\u003c/strong\u003e capabilities sufficient to identify, detect, protect, respond, and recover from security incidents (as per the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-cybersecurity-framework-csf\"\u003eNIST Cybersecurity Framework\u003c/a\u003e)\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMeet federal reporting requirements\u003c/strong\u003e for information security and privacy, including documenting and mitigating weaknesses and reporting incidents and breaches\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eManage privacy requirements\u003c/strong\u003e by working collaboratively with Data Guardians and Privacy Advisors\u003c/p\u003e\u003cp\u003eThe official role and specific responsibilities for ISSOs are outlined in detail by the CMS Information Security and Privacy Policy (IS2P2), which is based upon the related policy document from HHS (IS2P). The following list is based on those policy documents and includes some key duties for ISSOs:\u003c/p\u003e\u003cul\u003e\u003cli\u003eComplete the security categorization for the FISMA system using the CFACTS tool\u003c/li\u003e\u003cli\u003eComplete and maintain the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan\u003c/a\u003e using the CFACTS tool\u003c/li\u003e\u003cli\u003eEnsure \u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e – and \u003ca href=\"/learn/penetration-testing\"\u003ePenetration Tests\u003c/a\u003e have been scheduled and completed in a timely manner\u003c/li\u003e\u003cli\u003eDevelop, document and maintain an inventory of hardware and software components within the FISMA system’s authorization boundary\u003c/li\u003e\u003cli\u003eCoordinate the development of a \u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan\u003c/a\u003e and ensure the plan is tested and maintained accordingly\u003c/li\u003e\u003cli\u003eMaintain primary responsibility for the actions and activities associated with the FISMA system receiving and maintaining an \u003ca href=\"/learn/authorization-operate-ato\"\u003eAuthority to Operate (ATO)\u003c/a\u003e\u003c/li\u003e\u003cli\u003eCoordinate with the ISO, BO, and CRA to manage information security and privacy risk\u003c/li\u003e\u003cli\u003eMonitor and update all POA\u0026amp;Ms in accordance with current requirements and instruction\u003c/li\u003e\u003cli\u003eSubmit recommendations to the CRA for system configuration deviations from the required baseline\u003c/li\u003e\u003cli\u003eIdentify the information security and privacy controls provided by the applicable infrastructure that are common controls for information systems;\u003c/li\u003e\u003cli\u003eCoordinate with the ISO, BO, and CRA to meet all collection, creation, use, dissemination, retention, and maintenance requirements for sensitive information in accordance with the Privacy Act, E-Government Act, and all other applicable guidance\u003c/li\u003e\u003cli\u003eCoordinate with the BO, Contracting Officer, ISO, and CISO to ensure that all requirements specified by the \u003ca href=\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eARS 5.1\u003c/a\u003e and the \u003ca href=\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\"\u003eRMH\u003c/a\u003e are implemented and enforced for applicable information and information systems\u003c/li\u003e\u003cli\u003eReport and manage IT Security and Privacy Incidents in accordance to the RMH and other applicable federal guidance\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eTypes of ISSO roles\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe specific type of ISSO role assigned to a system will depend on the needs of the system and the available personnel. The descriptions below are taken from the CMS Information Security and Privacy Policy (IS2P2).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrimary Information System Security Officer (P-ISSO)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS P-ISSO may be either a federal government employee or a contractor and must fulfill all of the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.24, System Security and System Privacy Officers. ISSO must ensure the duties of the Security Control Assessor and Contingency Planning Coordinator are completed as described in the IS2P Sections 7.26 and 7.30.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecondary Information System Security Officer (S-ISSO)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS S-ISSO may be either a federal government employee or a contractor identified in the IS2P Section 7.25, ISSO Designated Representative / Security Steward and must assist the P-ISSO.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInformation System Security Officer Contractor Support (ISSOCS)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe ISSOCS is a contractor-only role that assists and supports the P-ISSO and S-ISSO roles in fulfillment of their CMS cybersecurity duties.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity or Privacy Control Assessor\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Security or Privacy Control Assessor role may be performed by an ISSO. The CMS Security or Privacy Control Assessor must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.23.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eContingency Planning Coordinator\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Contingency Planning Coordinator may either be a federal government employee or a contractor. The role may also be performed by an ISSO. The CMS Contingency Planning Coordinator must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.30.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eISSO checklist\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThis section provides a list of specific tasks an ISSO should perform periodically. The timelines listed for each task are general guidelines, which may vary depending on the Component guidance or system circumstances. This list isn’t comprehensive, but serves as a quick reference to help you plan your work. You may choose to make a spreadsheet for yourself to keep track of recurring tasks and due dates.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eWeekly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview audit logs\u003c/li\u003e\u003cli\u003eRoutinely evaluate risk posture based upon change requests\u003c/li\u003e\u003cli\u003eEnsure data is backed up\u003c/li\u003e\u003cli\u003eCheck status of any \u003ca href=\"/learn/plan-action-and-milestones-poam\"\u003ePlan of Action and Milestones (POA\u0026amp;M)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eMonthly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview / deactivate unused accounts\u003c/li\u003e\u003cli\u003eEnsure all POA\u0026amp;Ms with Open or Delay status are annotated with current status\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eQuarterly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsure that all data in CFACTS is current and accurate one week before the end of the quarter (CMS submits a quarterly FISMA report to OMB based on this data)\u003c/li\u003e\u003cli\u003eEnsure the completion of internal vulnerability scans\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eAnnually\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview and update all \u003cstrong\u003eSecurity Authorization Process documentation\u003c/strong\u003e, such as those listed below. Remember that most of these require months of effort to complete, so you must be working on them well in advance.\u003cul\u003e\u003cli\u003e\u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eInformation System Risk Assessment (ISRA)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan (CP)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePrivacy Impact Assessment (PIA)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e Note: Updating security control implementation is a necessary first step to updating the SSPP. When updating any documents, ensure the old copy is retained.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eEnsure that all system users and people with significant security responsibilities (e.g., ISSOs) receive their required annual awareness training\u003c/li\u003e\u003cli\u003eConduct a Contingency Plan Test with associated training, after-action, and updated POA\u0026amp;Ms as necessary. Ensure that the Business Owner certifies (signs) any updated CP document.\u003c/li\u003e\u003cli\u003eReview the Privacy Impact Assessment (PIA) for your system(s) and update as appropriate\u003c/li\u003e\u003cli\u003eEnsure vulnerability assessments are completed at least annually, or when significant changes are made to the system\u003c/li\u003e\u003cli\u003eReview and validate user access rights\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOngoing\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eContinual security control assessment to ensure no risks are present\u003c/li\u003e\u003cli\u003eContinual work on tests and assessments (as needed) such as:\u003cul\u003e\u003cli\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/li\u003e\u003cli\u003ePenetration Testing\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eContinual updating of the \u003cstrong\u003eSecurity Authorization Process documentation\u003c/strong\u003e (see list in the section above). All of these should be updated as changes occur, and all require an annual review and update.\u003c/li\u003e\u003cli\u003eComplete incident response reports (as required)\u003c/li\u003e\u003cli\u003eATO updates (as required)\u003c/li\u003e\u003cli\u003eRespond to any CCIC monitoring alerts (as required)\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eISSO activities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eUse this section to learn in-depth about the activities you must understand and perform as an ISSO – from the very beginning of your system’s development. These activities support the CMS \u003ca href=\"https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/tlc\"\u003eTarget Life Cycle\u003c/a\u003e (TLC), which is the framework that standardizes how IT systems are built, maintained, and retired at CMS. The ISSO activities also support the Risk Management Framework (RMF) from NIST, which helps organizations integrate security considerations into their software development processes.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eConduct a Security Impact Analysis (SIA)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe \u003ca href=\"/learn/security-impact-analysis-sia\"\u003eSecurity Impact Analysis\u003c/a\u003e\u0026nbsp;is the process that you will use initially for your new system and \u003cstrong\u003eevery time\u003c/strong\u003e a new change to the system is proposed. When you have completed this process, you will be able to provide substantive recommendations to your Business Owner on the impact of any proposed change(s). The impact may be small, or it may rise to the level of a new ATO process.\u003c/p\u003e\u003cp\u003eNote:\u0026nbsp; SIAs are frequently thought of as documents.\u0026nbsp; Remember that \u003cstrong\u003eSIA is a process\u003c/strong\u003e.\u0026nbsp; Based on the complexity and extent of the process, a completed form may help better describe the security impact, as well as necessary actions to take.\u0026nbsp; The actual CMS/FISMA requirement noted in ARS 5.1 Control CM-4 requires “Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) to conduct security impact analyses.”\u0026nbsp; It is up to you and your Business Owner/organization to determine the level to which you document your analysis.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-impact-analysis-sia\"\u003eLearn about Security Impact Assessment (SIA)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCategorize your FISMA system\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eYour FISMA system has different security controls based on the sensitivity of the information contained in or processed by your system. Categorization takes place within CFACTS.\u0026nbsp; You enter the appropriate area and select the type of information that will be processed.\u0026nbsp; The system categorization will be suggested automatically and noted as “Low”, “Moderate”, or “High”.\u0026nbsp; If necessary, the categorization may be manually overridden; your CRA will have to help with this.\u0026nbsp; In practice this seldom happens.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis system categorization will have a variety of uses.\u0026nbsp; Most importantly, you will need to have this information to determine which controls to allocate for your system.\u003c/p\u003e\u003cp\u003eNote: Although this process sounds like it will only be done once for your FISMA system, \u003cstrong\u003eyou may have to repeat it\u003c/strong\u003e if a proposed change includes access or storage of different types of data. \u0026nbsp; Your completed SIA will guide your actions.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/federal-information-security-modernization-act-fisma#perform-system-risk-categorization\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eLearn more about system categorization here\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/posts/watch-and-learn-system-categorization-cfacts\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eSee how to categorize your system in CFACTS\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eDetermine the Authorization Boundary\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAnother major initial task is to determine the system’s \u003cstrong\u003eAuthorization Boundary\u003c/strong\u003e. The NIST definition of authorization boundary is: “All components of an information system to be authorized for operation by an authorizing official and excludes separately authorized systems, to which the information system is connected”.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eOne practical way of determining the system’s authorization boundary is to ask whether a particular component can be changed by one’s system team, or if another team has to make updates or changes.\u0026nbsp; If your team can make the change or configuration, chances are that the component falls within your authorization boundary. As with system categorization, the authorization boundary is usually determined at the outset of system development. It may expand or contract based on changes to the system over its lifecycle.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBe aware of High Value Assets (HVAs)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe HHS HVA Program Policy defines HVAs as: “Assets, federal information systems, information, and data for which an unauthorized access, use, disclosure, disruption, modification, or destruction could cause a significant impact to the United States’ national security interests, foreign relations, economy, or to the public confidence, civil liberties, or public health and safety of the American people.”\u003c/p\u003e\u003cp\u003eThe practical impact of this program is that, if your FISMA system is defined as an HVA, it will face additional security requirements from DHS and HHS, which may impact the continuity operations and assessments of the system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAllocate controls\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOnce a system has been categorized, the ISSO has the information necessary to select controls, or allocate them.\u0026nbsp; The process is largely automatic, and is well-described in the CMS Risk Management Handbook (RMH) Chapter 12: Security and Privacy Planning. Selected controls are allocated for Low, Moderate, or High systems based on system categorization. The mechanics are described very well in the CFACTS User Manual, so that should be your primary reference point on allocating controls. Some general control types include:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSystem-specific controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThese are controls that your system “owns”.\u0026nbsp; If you are running on hardware that you are responsible for, there are system-specific controls for it.\u0026nbsp; If your system is an application, or Major Application, the system-specific controls are those controls that your developers and administrators configure and maintain.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInherited controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIn many cases your system uses components provided by other FISMA systems. In the above example about hardware, what if your system is housed on hardware administered by others? This is not just a possibility – in most cases major applications run within a separate data center. Certainly this is the case for systems housed in the AWS Cloud. In these instances, the data center (or other entity) that houses your system will most likely take care of some of the controls for your system – in which case your system will be able to “inherit” controls.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf the providing system completely takes care of a control, it is called a \u003cstrong\u003ecommon, or fully inherited\u003c/strong\u003e control. If the providing system takes care of part of a control, and relies on your system to take care of the rest of the control, it is called a \u003cstrong\u003ehybrid\u003c/strong\u003e control. (The CFACTS User Manual has additional information on how to inherit a control.)\u003c/p\u003e\u003cp\u003eUnderstanding which controls your team must address and which controls are available through full or partial inheritance will help you understand how to document your security control compliance (which is the next step in the cycle).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSupplemental controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSupplemental controls (previously referred to as non-mandatory controls in ARS 3.1) can be added to a system as necessary, and are not included in baseline control allocation. They should be reviewed and added as appropriate for your system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eImplement security controls\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIt is your responsibility as your system’s security and privacy Subject Matter Expert to make sure that your Business Owner, system developers, and system administrators understand the controls that must be in place for your system to be “secure” to CMS standards.\u0026nbsp; Once these controls have been implemented, \u003cstrong\u003ethey need to be documented within CFACTS\u003c/strong\u003e.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote:\u0026nbsp; All security controls that have been allocated for your system \u003cstrong\u003emust have some comment\u003c/strong\u003e. \u0026nbsp; Even fully inherited controls should have a notation that the control is fully inherited.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDevelop system documentation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eProminent documents are important to understanding the security posture of your FISMA system.\u0026nbsp; CFACTS can help with this process by automatically generating some of the documents, such as the System Security Plan. Other documents are found within CFACTS, such as System Categorization. Others, such as the Information System Risk Assessment (ISRA) must be completed using CMS-approved templates. Finally, others may either use a CMS template or a locally generated document such as the Security Impact Assessment (SIA).\u003c/p\u003e\u003cp\u003eNote:\u003cstrong\u003e Make sure that all CFACTS entries, including all security controls, are accurate and complete at all times.\u0026nbsp;\u003c/strong\u003e This will ensure that CFACTS-generated documents are accurate.\u003c/p\u003e\u003cp\u003eItems for the system documentation include:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSystem Security and Privacy Plan (SSPP)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSSPP\u003c/a\u003e is the key document associated with the FISMA system security. It should provide an accurate, detailed description of the FISMA system itself, security requirements, and those controls that are actually in place to protect the system. This document is generated by CFACTS.\u003c/p\u003e\u003cp\u003eTip: It is a best practice to maintain older copies of SSPPs as new versions are generated. Do not overwrite old SSPPs; you never can tell when you might need to refer to an older version.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eLearn more about System Security and Privacy Plan (SSPP)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInformation System Risk Assessment (ISRA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eISRA\u003c/a\u003e details the business and technical risks associated with a FISMA system.\u0026nbsp; It shares high-level information from CFACTS, as well as specific risks noted and how critical they are.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eLearn more about Information System Risk Assessment (ISRA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrivacy Impact Assessment (PIA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePIA\u003c/a\u003e is not simply a compliance step – it guides the full analysis of a system for privacy risks and controls. A PIA is a process for assessing whether appropriate privacy policies, procedures, business practices, and security controls are implemented to ensure compliance with federal privacy regulations. PIAs are published on HHS.gov and go through a three-year review process.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003eLearn more about Privacy Impact Assessment (PIA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eThird-Party Websites and Applications\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"https://www.osec.doc.gov/opog/privacy/Memorandums/OMB_M-10-23.pdf\"\u003eOffice of Management and Budget Memorandum 10-23\u003c/a\u003e, Guidance for Agency Use of Third-Party Websites and Applications, requires that agencies assess their uses of third-party websites and applications to ensure that the use protects privacy. The mechanism by which agencies perform this assessment is a privacy impact assessment (PIA).\u0026nbsp;\u003c/p\u003e\u003cp\u003eIn accordance with HHS policy, operating divisions (OPDIVs) are responsible for completing and maintaining PIAs for all third-party websites and applications in use. Upon completion of each assessment, agencies are required to make the PIAs publicly available. The CMS Third-Party Websites and Applications (TPWA) Privacy Impact Assessments for each individual OPDIV system can be \u003ca href=\"https://www.hhs.gov/pia/index.html#Third-Party\"\u003eaccessed here on the HHS website\u003c/a\u003e. CMS implementation specifications are included in the CMS Acceptable Risk Safeguards (ARS 5.1).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrivacy Threshold Analysis\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eA Privacy Threshold Analysis (PTA) is a PIA for a system that does not contain PII or only contains HHS employee information. PTAs remain internal to HHS and do not have to go through the three-year review process. A PTA may be updated based on a major change to the system. It is also possible that change to a system could result in a PTA then meeting the threshold to be a PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eConduct Contingency Planning (CP)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://dkanreserve.prod.acquia-sites.com/policy-guidance/risk-management-handbook-chapter-6-contingency-planning-cp\"\u003eContingency Planning\u003c/a\u003e\u0026nbsp;provides instructions, disaster declaration criteria, and procedures to recover information systems and associated services after a disruption. It involves cooperation with your Business Owner, your data center or hosting facility, and senior CMS leadership. (See CMS Risk Management Handbook Chapter 6: Contingency Planning).\u003c/p\u003e\u003cp\u003eAs the ISSO, you will coordinate efforts with your Business Owner to determine the business criticality of key processes. This effort will result in a Business Impact Analysis (BIA) which, in turn, serves as the primary requirement document for determining key recovery metrics including the Recovery Point Objective (RPO), Recovery Time Objective (RTO), Maximum Tolerable Downtime (MTD), and Work Recovery Time (WRT).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe goal is to ensure that there are plans in place to restore business functionality within the Maximum Tolerable Downtime.\u0026nbsp; Note that this may involve restoring the system as originally constructed, moving to alternate processing facilities, or even moving to alternate processing methods.\u0026nbsp;\u003c/p\u003e\u003cp\u003eHere are the key steps and documents involved in Contingency Planning:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCreate Contingency Plan (CP) document\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CP Plan is a single document that contains:\u003c/p\u003e\u003cul\u003e\u003cli\u003eKey recovery metrics for your FISMA system\u003c/li\u003e\u003cli\u003ePre-defined descriptions of conditions that constitute a need for action\u003c/li\u003e\u003cli\u003ePre-defined actions based on the severity of an identified incident\u003c/li\u003e\u003cli\u003eKey staff, contact information, and specific duties for each person\u003c/li\u003e\u003cli\u003eItem-level understanding of all of the hardware and software components of the FISMA system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIt’s important to keep in mind:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CP must be attested to (signed) by the FISMA System Owner annually.\u003c/li\u003e\u003cli\u003eAll of the information necessary for the conducting of a contingency plan must be in the CP.\u0026nbsp; There should be no references to offline personnel lists, contact information, system information, etc.\u0026nbsp;\u003c/li\u003e\u003cli\u003eAll identified Key Personnel must have access to their own copy of the CP in a secure location that is accessible in the event that the FISMA system is unavailable.\u003c/li\u003e\u003cli\u003eThe Contingency Plan, above all FISMA system documentation, must remain current.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eConduct Contingency Plan (CP) Exercise\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CP must be exercised (tested) at least once every 365 days. This is commonly referred to as the “Tabletop Exercise”, but a tabletop exercise is only one (the easiest) way to test the CP. An exercise plan must be prepared and followed during the execution of the test. All staff who participate in an actual CP event must be available for the exercise.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote: \u003cstrong\u003eKey staff members must be trained annually in their contingency responsibilities.\u003c/strong\u003e It is best to perform this training immediately prior to the exercise. Training in this way refreshes individuals’ memories and ensures their availability for the test.\u003c/p\u003e\u003cp\u003e\u003cem\u003eTip: If your FISMA system is involved in an outage that causes you to exercise the CP Plan, you should consider documenting this event as an exercise of your CP Plan.\u003c/em\u003e\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/contingency-plan\"\u003eLearn more about Contingency Plan testing\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eGet after action report\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAfter the exercise is conducted, an after action report must be generated to describe the test and highlight specific deficiencies that must be corrected.\u0026nbsp; These deficiencies may be easily correctable, or may result in POA\u0026amp;Ms.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eAchieve Contingency Plan (CP) re-certification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAfter any corrections have been made, the updated Contingency Plan must be re-certified by the System Owner. Make sure that all key staff members receive updated CP documents that they have access to (\u003cstrong\u003eeven away from the office or after hours\u003c/strong\u003e). Destroy (or return) older copies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAssess security controls for your system(s)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems are required to undergo assessments of risk and security/privacy control compliance before they are given Authorization to Operate (ATO). The assessment and authorization process protects the security and privacy posture of CMS systems throughout the system development lifecycle.\u0026nbsp;\u003c/p\u003e\u003cp\u003eAssessments of risk and/or control compliance are conducted:\u003c/p\u003e\u003cul\u003e\u003cli\u003eWhen a new system is ready to be placed into an operational state\u003c/li\u003e\u003cli\u003eWhen a significant change has been made to an existing system\u003c/li\u003e\u003cli\u003eAnnually, if a system follows a FISMA 1/3 assessment schedule\u003c/li\u003e\u003cli\u003eAd hoc when requested or otherwise required\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCurrently there are two main types of controls assessments – SCA and ACT.\u0026nbsp; Your component will dictate which type of assessment your system undergoes.\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote: Whichever one your system uses, make sure to schedule your assessment \u003cstrong\u003eas soon as possible\u003c/strong\u003e. When the assessment is complete, make sure all documentation is complete and housed in CFACTS appropriately.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity Controls Assessment (SCA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis is a detailed evaluation of the controls protecting an information system.\u0026nbsp; The security controls assessment determines the extent to which controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-controls-assessment-sca\"\u003eLearn more about Security Controls Assessment (SCA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCybersecurity and Risk Assessment Program (CSRAP) (Formally Adaptive Capabilities Testing (ACT))\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCSRAP is a security and risk assessment for FISMA systems at CMS. CSRAP assesses a system's security capabilities to ensure that it operates as intended and meets the security requirements for the information system. CSRAP is a critical component of the \u003ca href=\"https://cybergeek.cms.gov/learn/authorization-operate-ato\"\u003eAuthorization to Operate (ATO)\u003c/a\u003e process and is used to determine the overall system security and privacy posture throughout the system development life cycle (SDLC). For detailed information about CSRAP, see \u003ca href=\"https://confluenceent.cms.gov/download/attachments/214794255/CSRAP%20Assessment%20Handbook%20v3.1.pdf?version=1\u0026amp;modificationDate=1711993052415\u0026amp;api=v2\"\u003eCybersecurity and Risk Assessment Program Handbook\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePenetration testing\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePenetration testing is performed on information systems or individual system components to identify vulnerabilities that could be exploited by bad actors. It is used to validate vulnerabilities or determine the degree of resistance that organizational information systems have to risk within a set of specified constraints (e.g., time, resources, and/or skills).\u0026nbsp;\u003c/p\u003e\u003cp\u003ePenetration testing attempts to duplicate the actions of internal and external bad actors in carrying out hostile cyber-attacks against the organization and allows a more in-depth analysis. It can be conducted on the hardware, software, or firmware components of an information system and can exercise both physical and technical security controls.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePenetration testing is performed on all High Value Assets (HVA) information systems within CMS at a frequency of every 365 days or when there has been a significant change to the system.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIt is considered to be part of the group of assessments required for CMS systems, and its results are recorded in CFACTS similarly to the controls assessments (SCA and/or ACT).\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/penetration-testing\"\u003eLearn more about penetration testing\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity Assessment Report (SAR) and CAAT file\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eFor all assessments, a final Security Assessment Report (SAR) chronicles the results of the assessment. The \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eRisk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization\u003c/a\u003e states:\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cem\u003eAt the completion of a security controls assessment, the independent assessor completes a CMS Assessment and Audit Tracking (CAAT) spreadsheet. The CAAT spreadsheet is utilized for all CMS audits, assessments and penetration testing vulnerabilities. The completed CAAT spreadsheet is emailed to the CMS CISO mailbox at \u003c/em\u003e\u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003e\u003cem\u003eCISO@cms.hhs.gov\u003c/em\u003e\u003c/a\u003e\u003cem\u003e for upload into the CFACTS tool. Once uploaded into CFACTS, the weaknesses are automatically generated for all items with a status of “other than satisfied”. The ISSO for the associated information system receives an automated email notification from the CFACTS tool identifying a new weakness. The ISSO has 30 days to create a POA\u0026amp;M within CFACTS.\u003c/em\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManage Plan of Action and Milestones (POA\u0026amp;M)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe POA\u0026amp;M is a remedial action plan (the process of accepting or resolving a risk) which helps the agency to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIdentify and assess information system security and privacy weaknesses\u003c/li\u003e\u003cli\u003eSet priorities about how to mitigate weaknesses using available resources\u003c/li\u003e\u003cli\u003eMonitor and report progress toward mitigating the weaknesses\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eYou – as the ISSO – are responsible for opening, maintaining / updating, and closing POA\u0026amp;Ms on a continual basis to ensure the maximum level of information security for system(s) entrusted to your care.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/plan-action-and-milestones-poam\"\u003eLearn more about Plan of Action \u0026amp; Milestones (POA\u0026amp;M)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthorize the system\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eSystem authorization is the formal decision by senior officials to allow a CMS information system to operate. Commonly known as Authorization to Operate (ATO), this is the culmination of all the tests, assessments, remediation, documentation, and other activities that the ISSO and others on the portfolio team have done to ensure information security for the system.\u003c/p\u003e\u003cp\u003eIn formal terms, authorization is described in the CMS Risk Management Handbook Chapter 4: Security Assessment and Authorization:\u003c/p\u003e\u003cp\u003e\u003cem\u003eSecurity authorizations are official management decisions that are conveyed through authorization decision documents by senior organizational officials or executives (i.e., authorizing officials) to authorize operation of information systems to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon security controls. The CIO serves as the authorizing official for CMS. The CIO is responsible for making an overall determination of risk and authorizing CMS information systems for operation, if it is determined that the associated risks are acceptable. An ATO memo is signed by the CIO giving the System Owner/BO formal authority to operate a CMS information system.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThere are three NIST document requirements for an ATO “package” and six more that are specific to CMS.\u0026nbsp; The documents include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eSystem Security and Privacy Plan (SSPP)\u003c/li\u003e\u003cli\u003eSecurity Assessment (Final) Report (SAR)\u003c/li\u003e\u003cli\u003ePlans of Action and Milestones (POA\u0026amp;M)\u003c/li\u003e\u003cli\u003eContingency Plan (CP)\u003c/li\u003e\u003cli\u003eCP Testing Plan\u003c/li\u003e\u003cli\u003eCP Test After Action Report\u003c/li\u003e\u003cli\u003eInformation System Risk Assessment (ISRA)\u003c/li\u003e\u003cli\u003ePrivacy Impact Assessment (PIA)\u003c/li\u003e\u003cli\u003eInterconnection Security Agreement (ISA) – as applicable\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eGetting these documents together and conducting all necessary steps can be a long process – so \u003cstrong\u003eyou should start working on your ATO as early as possible\u003c/strong\u003e to ensure timely completion.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/authorization-operate-ato\"\u003eLearn more about System Authorization\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eContinuous monitoring\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eContinuous monitoring is the practice of using modern tools and technology to continuously check systems for vulnerabilities and risks. Rather than thinking of getting an ATO as having “achieved” compliance, continuous monitoring allows us to observe and track evolving risks over time. Security is never “done”.\u003c/p\u003e\u003cp\u003eContinuous monitoring is a growing program at CMS. As an ISSO, you will work closely with the CMS Cybersecurity Integration Center (CCIC) to ensure that your system is appropriately monitored.\u0026nbsp; CCIC ensures oversight of information security and privacy, including Security Information Event Management, for each FISMA system operating by or on behalf of CMS.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe CCIC delivers various agency-wide security services.\u0026nbsp; These services include \u003ca href=\"/learn/continuous-diagnostics-and-mitigation-cdm\"\u003eContinuous Diagnostics and Mitigation (CDM)\u003c/a\u003e as well as security engineering, incident management, forensics and malware analysis, information sharing, cyber threat intelligence, penetration testing, and software assurance.\u003c/p\u003e\u003cp\u003eMore information about continuous monitoring can be found in the \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eCMS Risk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManage security incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAlong the way, a system entrusted to your care might have a security or privacy incident or breach. Anytime there is a violation of computer security policies, acceptable use policies, or standard security practices at CMS, it is considered an\u003cstrong\u003e incident\u003c/strong\u003e. If an incident involves the loss of control or unauthorized disclosure of Personally Identifiable Information (PII), then the incident is considered a \u003cstrong\u003ebreach\u003c/strong\u003e.\u003c/p\u003e\u003cp\u003eKnown or suspected security or privacy incidents involving CMS information or information systems \u003cstrong\u003emust be reported immediately\u003c/strong\u003e to the CMS IT Service Desk:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePhone: 410-786-2580 or 1-800-562-1963\u003c/li\u003e\u003cli\u003eEmail: \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e.\u0026nbsp;\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eYou as the ISSO should be apprised of the situation as soon as possible (if you’re not the one who initially reported the incident). You will work with the Incident Management Team (IMT) and others involved with your system to manage and report the incident and mitigate any resulting harm. More details can be found in the CMS Risk Management Handbook (RMH) Chapter 8: Incident Response.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eISSO toolkit\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis section contains links to documents you will access often in your daily activities, and resources to support your work as an ISSO. You should become familiar with the purpose and usage of each.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDocuments\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCMS Acceptable Risk Safeguards (ARS 5.1)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Information Security Acceptable Risk Safeguards (ARS 5.1) defines information security and privacy control requirements and includes additional, detailed policy traceability statements within each control description. The ARS 5.1 provides guidance on customizing (tailoring) controls and enhancements for specific types of missions/business functions, technologies, or environments of operation. Users of the ARS 5.1 may tailor specific mandatory controls as well as most of the non-mandatory and unselected controls.\u003c/p\u003e\u003cp\u003eThe goal of the ARS 5.1 is to define a baseline of minimum information security and privacy assurance controls. The controls are based on both internal CMS governance documents and laws, regulations, and other authorities created by institutions external to CMS. Protecting and ensuring the confidentiality, integrity, and availability for all of CMS’ information and information systems is the primary purpose of the information security and privacy assurance program. The ARS 5.1 complies with the CMS IS2P2 by providing a defense-in-depth security structure along with a least-privilege, need-to-know basis for all information access.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cybergeek.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eLearn more about ARS 5.1\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Information Security and Privacy Policy (IS2P2)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis policy defines the framework under which CMS protects and controls access to CMS information and information systems. It provides direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems; systems maintained on behalf of CMS; and other collections of information to assure the confidentiality, integrity, and availability of CMS information and systems.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eAlong with the Acceptable Risk Safeguards (ARS 5.1), the IS2P2 stands as one of the core reference sources for cybersecurity policies and practices at CMS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eGo to the IS2P2\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Risk Management Handbooks\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis series of handbooks is designed to help ISSOs understand and address the many CMS security and privacy requirements developed to protect their system(s). The RMH chapters are generally aligned to provide specific guidance and recommendations for specific ARS 5.1 Control Families. (For example, \u003cstrong\u003eRMH Chapter 6: Contingency Planning\u003c/strong\u003e addresses the ARS 5.1 controls in the \u003cstrong\u003eCP Family\u003c/strong\u003e.) As you work through your ARS 5.1 controls, you should have the appropriate RMH handy.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\"\u003eLearn more about the CMS Risk Management Handbook (RMH)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTools and resources\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCFACTS\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS FISMA Controls Tracking System (CFACTS) is the system used by CMS as a repository for managing the security and privacy requirements of its information systems. It provides a common foundation to manage policies, controls, risks, assessments, and deficiencies across the CMS enterprise. You will use it for tracking your tasks associated with system authorization, risk remediation, and more.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cfacts3.cms.cmsnet/apps/ArcherApp/Home.aspx#home\"\u003eGo to CFACTS\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003cp\u003eA user manual is produced by the team that administers CFACTS and gives a guided tour through all activities in CFACTS. Although it is not a primer in risk management, many activities and concepts can be understood implicitly through their description in the User Manual and implementation in CFACTS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cfacts3.cms.cmsnet/apps/ArcherApp/Home.aspx\"\u003eGo to CFACTS user manual\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISPG website (CyberGeek)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe Information Security and Privacy Group (ISPG) provides the “CyberGeek” website as a one-stop shop for all security and privacy related information at CMS – including dedicated resource pages for ISSOs and other roles. This is a new site, and more information will become available as it grows.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://security.cms.gov/\"\u003eGo to ISPG website (CyberGeek)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Slack\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSlack is an application that allows for fast and easy communication among all CMS employees and contractors. Spaces called channels allow for focused communication which will keep you organized and informed during your daily routine. Below is a list of Slack channels that will help you on your journey to becoming a fully independent ISSO:\u003c/p\u003e\u003cul\u003e\u003cli\u003e#ars-feedback\u003c/li\u003e\u003cli\u003e#cfacts_community\u003c/li\u003e\u003cli\u003e#cisab\u003c/li\u003e\u003cli\u003e#cms-isso\u003c/li\u003e\u003cli\u003e#cyber-risk-management\u003c/li\u003e\u003cli\u003e#ispg-all\u003c/li\u003e\u003cli\u003e#isso-as-a-service\u003c/li\u003e\u003cli\u003e#security_community\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAcronyms\u003c/h4\u003e\u003cp\u003eLike most other parts of government, the security and privacy world at CMS is full of acronyms. ISPG maintains a list of acronyms so you can easily look up unfamiliar terms.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/acronyms\"\u003eSee the acronym list here\u003c/a\u003e.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Framework\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAs an ISSO, your daily tasks support CMS in applying the NIST Cybersecurity Framework (CSF), guidance created by the National Institute of Standards and Technology to help organizations effectively manage cybersecurity risk. (Executive Order 13800, \u003ca href=\"https://www.federalregister.gov/documents/2017/05/16/2017-10004/strengthening-the-cybersecurity-of-federal-networks-and-critical-infrastructure\"\u003eStrengthening the Cybersecurity of Federal Networks and Critical Infrastructure\u003c/a\u003e, made the Framework mandatory for U.S. federal government agencies.)\u003c/p\u003e\u003cp\u003eWe have created the \u003cstrong\u003eISSO Framework\u003c/strong\u003e to show how ISSO responsibilities align with specific functions and categories of the NIST Cybersecurity Framework, and how the ISSO works with other people within the organization to complete tasks. You can refer to this Framework whenever you have questions about documentation or activities related to your job.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://share.cms.gov/Office/OIT/ISPG/DSPC/ISPG%20DSPC%20Documents%20%20Internal/ISSO%20Engagement%20and%20Outreach%20Initiative/ISSO%20Framework\"\u003eGo to the ISSO Framework\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity and Privacy Language for IT Procurements\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS provides templated language to use in IT procurements to ensure the security and privacy of information and information systems that CMS uses. This includes systems provided or managed by contractors or subcontractors on behalf of CMS. The ISSO may provide support to this process.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-and-privacy-requirements-it-procurements\"\u003eLearn more about Security and Privacy Language for IT Procurements\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eTarget Life Cycle (TLC)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS requires all new IT systems to follow the Target Life Cycle (TLC), a common framework for governing system development across the enterprise. The TLC accommodates various IT development methodologies while ensuring that systems meet all applicable legislative and policy requirements.\u0026nbsp;\u003c/p\u003e\u003cp\u003e(The TLC has replaced the former Expedited Life Cycle (XLC) as the official IT governance framework at CMS. If your current projects or contracts specify the use of XLC-related tools, templates, or reviews, you may continue using them.\u0026nbsp; You may also use fewer or alternative tools and templates, as long as you meet the minimum requirements outlined within the TLC.)\u003c/p\u003e\u003cp\u003eAs an ISSO, you will enter the TLC by filling out an intake form when:\u003c/p\u003e\u003cul\u003e\u003cli\u003eInitiate a new IT project\u003c/li\u003e\u003cli\u003eConduct an acquisition to support a new IT project\u003c/li\u003e\u003cli\u003eRequest new/increased funding to support an IT project\u0026nbsp;\u003c/li\u003e\u003cli\u003ePlan significant changes to an existing IT project\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAfter submitting your form, the CMS IT Governance Team will help you meet TLC requirements. You can also contact the governance team via email: \u003ca href=\"mailto:IT_Governance@cms.hhs.gov\"\u003eIT_Governance@cms.hhs.gov\u003c/a\u003e\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/TLC\"\u003eLearn more about the TLC\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://share.cms.gov/Office/OIT/CIOCorner/Lists/Intake/NewForm.aspx\"\u003eFill out an intake form\u003c/a\u003e (requires CMS login)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eResources external to CMS\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eHHS Policy for Information Security and Privacy Protection (IS2P)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe Department of Health and Human Services (HHS) is the parent organization for CMS. All of our policies and guidance are based on HHS-level documentation. The IS2P comprises HHS policies and procedures that ensure the secure collection, use, sharing, and storage of information that is both terrorism-related information and “protected information (PI)”.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWhere possible, this document identifies existing HHS policies and procedures that meet the privacy requirements. Where necessary, however, this document also creates policies specific to the activities and resources that HHS requires.\u0026nbsp; The IS2P is one of the base documents from which CMS requirements are created. You can request a copy of this policy from the CISO team: \u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003eCISO@cms.hhs.gov\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eHHS Cybersecurity Library\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSometimes CMS borrows policies and standards directly from HHS, our parent organization. You will sometimes need to access the HHS library of cybersecurity documents for your work.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://intranet.hhs.gov/security/index.html\"\u003eGo to the HHS library\u003c/a\u003e (requires login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNIST Special Publications\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eNIST Special Publications in the 800 series are of general interest to the computer security community, and these documents serve as the foundation for CMS security and privacy practices. Specifically helpful to ISSOs are the publications that contain detailed explanations of information security controls and the test cases used to assess them.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53: Recommended Security Controls for Federal Information Systems\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final\"\u003eNIST SP 800-53A: Guide for Assessing the Security Controls in Federal Information Systems\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-800-series-of-special-publications\"\u003eLearn more about NIST SP 800 series\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNIST Computer Security Resource Center\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe National Institute of Standards and Technology (NIST) publishes helpful resources on computer, cyber, and information security and privacy. Explore publications, news, programs, and events that will help you expand your cybersecurity knowledge.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/\"\u003eVisit the NIST Resource Center\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eOMB Memoranda and Circulars\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eEvery year, the Office of Management and Budget (OMB) publishes a Memo with reporting instructions and guidance for FISMA, which can be useful to people with cybersecurity responsibilities at CMS. \u003ca href=\"https://www.whitehouse.gov/omb/information-for-agencies/memoranda/\"\u003eExplore OMB memos here\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eThere are a number of OMB Circulars that provide general guidance on information security. Three of the most relevant are:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/omb/circulars_a130_a130appendix_iii\"\u003eA-130 - Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.osec.doc.gov/opog/privacy/Memorandums/OMB_Circular_A-123.pdf\"\u003eA-123 - Management's Responsibility for Internal Control\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/omb/circulars_a127/\"\u003eA-127 - Financial Management Systems\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eOMB A-130 applies to all IT systems while A-123 and A-127 apply primarily to financial systems. ISSOs should be aware of these foundation documents and have a general understanding of their content. \u003ca href=\"https://www.whitehouse.gov/omb/information-for-agencies/circulars/\"\u003eExplore all OMB Circulars here\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho to contact\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWhen you have a question or challenge, we are here to help! Here are key points of contact for situations you may face as an ISSO.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity or privacy incident\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eReport known or suspected security or privacy incidents involving CMS data to the CMS IT Service Desk by calling 410-786-2580 or 1-800-562-1963 or via e-mail to \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity or privacy questions\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eDo you have a question or concern related to CMS information security or privacy, and need a place to start? Send an email to the CISO Team at \u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003eCISO@cms.hhs.gov\u003c/a\u003e regarding information security, or an email to \u003ca href=\"mailto:Privacy@cms.hhs.gov\"\u003eprivacy@cms.hhs.gov\u003c/a\u003e for questions regarding information privacy.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eISSO questions\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eIf you have questions about the ISSO role or other activities such as the ISSO Forum —or if you just want to hear from an ISSO — send an email to \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eOversight and guidance\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Cyber Risk Advisor (CRA) and Privacy Advisor are your ISPG support representatives. They help improve accountability and risk management by providing hands-on oversight to system cybersecurity and privacy risk.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eISSO community\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCMS Cybersecurity Community Forum (C3F)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis monthly meeting is held for the benefit of the CMS security community, covering timely and relevant topics from ISPG speakers. It’s open to all CMS and contractor security professionals. Meeting details (location, time, video conferencing link) will be in the email invitation, which is sent monthly to everyone at CMS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://confluenceent.cms.gov/pages/viewpage.action?spaceKey=IIP\u0026amp;title=CMS+ISSO+Forum\"\u003eSee past Forum videos and materials\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Journal\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eRead the ISSO Journal to stay updated on cybersecurity trends, learn about current events, and hear from other ISSOs. The Journal is distributed widely among CMS staff, and all cybersecurity professionals – both CMS and contractor staff – are invited to contribute! Contact us by email (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e) if you would like to write a post.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://confluenceent.cms.gov/pages/viewpage.action?spaceKey=IIP\u0026amp;title=CMS+ISSO+Journal\"\u003eRead the ISSO Journal\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Mentorship Program\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe mentorship program allows experienced ISSOs to support those who are newer to the role. For mentors, this is an opportunity to build leadership skills and strengthen the future of cybersecurity at CMS. For mentees, this allows you to build your knowledge faster and get hands-on support. The structure of the program is flexible — both ISSOs will decide what cadence and duration for meetings works for them.\u0026nbsp;\u003c/p\u003e\u003cp\u003eA mentorship usually lasts 6 months to a year. Your supervisor will need to approve your participation in the program.\u0026nbsp; Note that although the program is generally used by newer ISSOs, it is also available for existing ISSOs who want additional bootstrap help – for example, if they are dealing with an issue or project that is new to them. Mentorship is for these ISSOs, too!\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/isso-mentorship-program\"\u003eLearn about the ISSO Mentorship Program\u003c/a\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eTraining\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePeople come to the ISSO role from many backgrounds, with differing experiences, so each may start at a different place. Broadly, ISSOs need to have both general cybersecurity knowledge and specific knowledge of how things operate at CMS. For new ISSOs, see the “Getting Started” section of this Handbook for tips on beginning your training journey.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNICE code for ISSOs\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere is a Federal initiative to help train cybersecurity professionals. The \u003ca href=\"https://www.nist.gov/itl/applied-cybersecurity/nice\"\u003eNational Initiative for Cybersecurity Education\u003c/a\u003e (NICE) seeks to link appropriate training to cybersecurity roles by associating NICE “codes” with training opportunities. \u003cstrong\u003eAs an ISSO, your NICE code is OV‐MGT‐001\u003c/strong\u003e. Knowing this will help you find appropriate training for particular tasks or knowledge areas.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTraining sources\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere are many external sources – such as professional associations and training organizations – that can help you expand your cybersecurity knowledge and skills, but you can also get excellent free training that is provided by CMS and HHS. They are offered via the following platforms:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"http://www.cms.gov/cbt\"\u003eCMS Computer Based Training\u003c/a\u003e (CBT) - Free online training courses provided by CMS\u003c/li\u003e\u003cli\u003eCMS Cybersecurity Training Catalog - List of current training offerings and events (such as webinars) from CMS\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://confluenceent.cms.gov/display/IIP/ISSO+Training\"\u003eISSO Training Page\u003c/a\u003e - Collection of training resources in the ISPG Confluence environment that helps you navigate the training options available to you\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://ams.hhs.gov/amsLogin/SimpleLogin.jsp\"\u003eHHS Learning Management System\u003c/a\u003e\u0026nbsp; (LMS) - Free courses for federal employees (not contractors) provided through HHS to advance your core cybersecurity knowledge or prepare you for certifications\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://fedvte.usalearning.gov/\"\u003eFederal Virtual Training Environment\u003c/a\u003e (FedVTE) - Another source of free training courses available to federal employees and contractors (similar to the LMS above).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eTo help ISSOs focus on the most relevant training, below is a list of Basic, Intermediate, and Advanced courses that will help you grow in the specific skills needed for your role.\u003c/p\u003e\u003ch4\u003eBasic ISSO training\u003c/h4\u003e\u003cp\u003eThe courses recommended below provide both an introduction to cybersecurity in general and guidance on how these concepts are implemented at CMS. The courses listed in bold are the most important. You should consider some or all of the rest of the courses as your time permits. If possible, try to complete the bolded courses within your first two months as an ISSO. There is no cost to take these courses. Note: HHS LMS is only available to federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eISSO Fundamentals\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWorking With CFACTS\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eClassroom / Remote\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eAll About the CMS Acceptable Risk Safeguards (ARS 5.1)\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePrivacy and Awareness Training\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eExecutive’s Guide to Security: Protecting Your Information\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Awareness: Getting Started with Security Foundations, Information Security Fundamentals, and Key Security Terms\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompliance Expert: IT Security - Phishing, Safeguarding Mobile Devices, and Privacy \u0026amp; Information Security (The Basics)\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity 101: Auditing \u0026amp; Incident Response and Session \u0026amp; Risk Management\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003eIntermediate ISSO training\u003c/h4\u003e\u003cp\u003eThe courses recommended below will build on your initial knowledge. As before, you should start with the courses listed in bold, or on topics that have immediate importance to you. There is no cost to take these courses. Note: HHS LMS is only available for federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eNavigating New Cybersecurity and Privacy Policies and Procedures\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eHow Hackers Hack and How to Protect Yourself\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eIncident Response at CMS\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCMS Privacy Incident Response: Quick Guide for Business Owners\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Race\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eFundamentals of Cyber Risk Management\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFoundations of Incident Management\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompliance Expert: IT Security - Phishing\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Audits\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eImplementation of Security Controls\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003eAdvanced ISSO training\u003c/h4\u003e\u003cp\u003eThe advanced courses recommended below will help you gain a deeper understanding of the cybersecurity issues that you have been working with. They may also be appropriate to take earlier if you entered the ISSO role with a good basic understanding of both CMS operations and cybersecurity in general. There is no cost to take these courses.\u0026nbsp; Note: HHS LMS is only available for federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eEmerging Cyber Security Threats\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecuring Infrastructure Devices\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecuring the Network Perimeter\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Computing Fundamentals: Cloud Security\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Architecture\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Security\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Platforms\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCloud Security Fundamentals\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA A+: Security Fundamentals\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eEncryption and Malware\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA Server+: Network Security Protocols\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA Cloud+\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e"])</script><script>self.__next_f.push([1,"2a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node_type/node_type/d185e460-4998-4d2b-85cb-b04f304dfb1b\"}\n29:{\"self\":\"$2a\"}\n2d:[\"menu_ui\",\"scheduler\"]\n2c:{\"module\":\"$2d\"}\n30:[]\n2f:{\"available_menus\":\"$30\",\"parent\":\"\"}\n31:{\"expand_fieldset\":\"when_required\",\"fields_display_mode\":\"vertical_tab\",\"publish_enable\":false,\"publish_past_date\":\"error\",\"publish_past_date_created\":false,\"publish_required\":false,\"publish_revision\":false,\"publish_touch\":false,\"show_message_after_update\":true,\"unpublish_enable\":false,\"unpublish_required\":false,\"unpublish_revision\":false}\n2e:{\"menu_ui\":\"$2f\",\"scheduler\":\"$31\"}\n2b:{\"langcode\":\"en\",\"status\":true,\"dependencies\":\"$2c\",\"third_party_settings\":\"$2e\",\"name\":\"Explainer page\",\"drupal_internal__type\":\"explainer\",\"description\":\"Use \u003ci\u003eExplainer pages\u003c/i\u003e to provide general information in plain language about a policy, program, tool, service, or task related to security and privacy at CMS.\",\"help\":null,\"new_revision\":true,\"preview_mode\":1,\"display_submitted\":true}\n28:{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"links\":\"$29\",\"attributes\":\"$2b\"}\n34:{\"href\":\"https://cybergeek.cms.gov/jsonapi/user/user/e352e203-fe9c-47ba-af75-2c7f8302fca8\"}\n33:{\"self\":\"$34\"}\n35:{\"display_name\":\"mburgess\"}\n32:{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"links\":\"$33\",\"attributes\":\"$35\"}\n38:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22?resourceVersion=id%3A131\"}\n37:{\"self\":\"$38\"}\n3a:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\n39:{\"drupal_internal__tid\":131,\"drupal_internal__revision_id\":131,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:13:33+00:00\",\"status\":true,\"name\":\"General Information\",\"description\":null,\"weight\":2,\"changed\":\"2023-03-10T19:04:03+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$3a\"}\n3e:{\"drupal_internal__target_id\":\"resource_type\"}\n3d:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"3a0127c4-ee06-41ed-8239-f796f6d78eb3\",\"meta\":\"$3e\"}\n40:{\"href\":\""])</script><script>self.__next_f.push([1,"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/vid?resourceVersion=id%3A131\"}\n41:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/vid?resourceVersion=id%3A131\"}\n3f:{\"related\":\"$40\",\"self\":\"$41\"}\n3c:{\"data\":\"$3d\",\"links\":\"$3f\"}\n44:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/revision_user?resourceVersion=id%3A131\"}\n45:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/revision_user?resourceVersion=id%3A131\"}\n43:{\"related\":\"$44\",\"self\":\"$45\"}\n42:{\"data\":null,\"links\":\"$43\"}\n4c:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\n4b:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$4c\"}\n4a:{\"help\":\"$4b\"}\n49:{\"links\":\"$4a\"}\n48:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"virtual\",\"meta\":\"$49\"}\n47:[\"$48\"]\n4e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/parent?resourceVersion=id%3A131\"}\n4f:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/parent?resourceVersion=id%3A131\"}\n4d:{\"related\":\"$4e\",\"self\":\"$4f\"}\n46:{\"data\":\"$47\",\"links\":\"$4d\"}\n3b:{\"vid\":\"$3c\",\"revision_user\":\"$42\",\"parent\":\"$46\"}\n36:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"links\":\"$37\",\"attributes\":\"$39\",\"relationships\":\"$3b\"}\n52:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5?resourceVersion=id%3A66\"}\n51:{\"self\":\"$52\"}\n54:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\n53:{\"drupal_internal__tid\":66,\"drupal_internal__revision_id\":66,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:26+00:00\",\"status\":true,\"name\":\"Cyber Risk Advisor (CRA)\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:26+00:00\",\"default_langcode\":true,\"r"])</script><script>self.__next_f.push([1,"evision_translation_affected\":true,\"path\":\"$54\"}\n58:{\"drupal_internal__target_id\":\"roles\"}\n57:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":\"$58\"}\n5a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/vid?resourceVersion=id%3A66\"}\n5b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/relationships/vid?resourceVersion=id%3A66\"}\n59:{\"related\":\"$5a\",\"self\":\"$5b\"}\n56:{\"data\":\"$57\",\"links\":\"$59\"}\n5e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/revision_user?resourceVersion=id%3A66\"}\n5f:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/relationships/revision_user?resourceVersion=id%3A66\"}\n5d:{\"related\":\"$5e\",\"self\":\"$5f\"}\n5c:{\"data\":null,\"links\":\"$5d\"}\n66:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\n65:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$66\"}\n64:{\"help\":\"$65\"}\n63:{\"links\":\"$64\"}\n62:{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":\"$63\"}\n61:[\"$62\"]\n68:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/parent?resourceVersion=id%3A66\"}\n69:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/relationships/parent?resourceVersion=id%3A66\"}\n67:{\"related\":\"$68\",\"self\":\"$69\"}\n60:{\"data\":\"$61\",\"links\":\"$67\"}\n55:{\"vid\":\"$56\",\"revision_user\":\"$5c\",\"parent\":\"$60\"}\n50:{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"links\":\"$51\",\"attributes\":\"$53\",\"relationships\":\"$55\"}\n6c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26?resourceVersion=id%3A81\"}\n6b:{\"self\":\"$6c\"}\n6e:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\n6d:{\"drupal_internal__tid\":81,\"drupal_internal__revision_id\":81,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:09:11+00:0"])</script><script>self.__next_f.push([1,"0\",\"status\":true,\"name\":\"Data Guardian\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:09:11+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$6e\"}\n72:{\"drupal_internal__target_id\":\"roles\"}\n71:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":\"$72\"}\n74:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/vid?resourceVersion=id%3A81\"}\n75:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/relationships/vid?resourceVersion=id%3A81\"}\n73:{\"related\":\"$74\",\"self\":\"$75\"}\n70:{\"data\":\"$71\",\"links\":\"$73\"}\n78:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/revision_user?resourceVersion=id%3A81\"}\n79:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/relationships/revision_user?resourceVersion=id%3A81\"}\n77:{\"related\":\"$78\",\"self\":\"$79\"}\n76:{\"data\":null,\"links\":\"$77\"}\n80:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\n7f:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$80\"}\n7e:{\"help\":\"$7f\"}\n7d:{\"links\":\"$7e\"}\n7c:{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":\"$7d\"}\n7b:[\"$7c\"]\n82:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/parent?resourceVersion=id%3A81\"}\n83:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/relationships/parent?resourceVersion=id%3A81\"}\n81:{\"related\":\"$82\",\"self\":\"$83\"}\n7a:{\"data\":\"$7b\",\"links\":\"$81\"}\n6f:{\"vid\":\"$70\",\"revision_user\":\"$76\",\"parent\":\"$7a\"}\n6a:{\"type\":\"taxonomy_term--roles\",\"id\":\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\",\"links\":\"$6b\",\"attributes\":\"$6d\",\"relationships\":\"$6f\"}\n86:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab?resourceVersion=id%3A61\"}\n85:{\"self\":\"$86\"}\n88:{\"alias\":null,\"pid\":null,\"langco"])</script><script>self.__next_f.push([1,"de\":\"en\"}\n87:{\"drupal_internal__tid\":61,\"drupal_internal__revision_id\":61,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:12+00:00\",\"status\":true,\"name\":\"Information System Security Officer (ISSO)\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:12+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$88\"}\n8c:{\"drupal_internal__target_id\":\"roles\"}\n8b:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":\"$8c\"}\n8e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/vid?resourceVersion=id%3A61\"}\n8f:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/vid?resourceVersion=id%3A61\"}\n8d:{\"related\":\"$8e\",\"self\":\"$8f\"}\n8a:{\"data\":\"$8b\",\"links\":\"$8d\"}\n92:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/revision_user?resourceVersion=id%3A61\"}\n93:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/revision_user?resourceVersion=id%3A61\"}\n91:{\"related\":\"$92\",\"self\":\"$93\"}\n90:{\"data\":null,\"links\":\"$91\"}\n9a:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\n99:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$9a\"}\n98:{\"help\":\"$99\"}\n97:{\"links\":\"$98\"}\n96:{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":\"$97\"}\n95:[\"$96\"]\n9c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/parent?resourceVersion=id%3A61\"}\n9d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/parent?resourceVersion=id%3A61\"}\n9b:{\"related\":\"$9c\",\"self\":\"$9d\"}\n94:{\"data\":\"$95\",\"links\":\"$9b\"}\n89:{\"vid\":\"$8a\",\"revision_user\":\"$90\",\"parent\":\"$94\"}\n84:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"links\":\"$85\",\"attributes\":\"$87\",\"relationships\":\"$89\"}\na0:{\"href\":\"https:/"])</script><script>self.__next_f.push([1,"/cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34?resourceVersion=id%3A76\"}\n9f:{\"self\":\"$a0\"}\na2:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\na1:{\"drupal_internal__tid\":76,\"drupal_internal__revision_id\":76,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:55+00:00\",\"status\":true,\"name\":\"System / Business Owner\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:55+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$a2\"}\na6:{\"drupal_internal__target_id\":\"roles\"}\na5:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":\"$a6\"}\na8:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/vid?resourceVersion=id%3A76\"}\na9:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/vid?resourceVersion=id%3A76\"}\na7:{\"related\":\"$a8\",\"self\":\"$a9\"}\na4:{\"data\":\"$a5\",\"links\":\"$a7\"}\nac:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/revision_user?resourceVersion=id%3A76\"}\nad:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/revision_user?resourceVersion=id%3A76\"}\nab:{\"related\":\"$ac\",\"self\":\"$ad\"}\naa:{\"data\":null,\"links\":\"$ab\"}\nb4:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\nb3:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$b4\"}\nb2:{\"help\":\"$b3\"}\nb1:{\"links\":\"$b2\"}\nb0:{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":\"$b1\"}\naf:[\"$b0\"]\nb6:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/parent?resourceVersion=id%3A76\"}\nb7:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/parent?resourceVersion=id%3A76\"}\nb5:{\"related\":\"$b6\",\"self\":\"$b7\"}\nae:{\"data\":\"$af\",\"links\":\"$b5\"}\na3:{\"vid\":\"$a4\",\"revision_user\":\"$aa\",\"parent\":\"$ae\"}\n9e:{\"type"])</script><script>self.__next_f.push([1,"\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"links\":\"$9f\",\"attributes\":\"$a1\",\"relationships\":\"$a3\"}\nba:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e?resourceVersion=id%3A71\"}\nb9:{\"self\":\"$ba\"}\nbc:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\nbb:{\"drupal_internal__tid\":71,\"drupal_internal__revision_id\":71,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:42+00:00\",\"status\":true,\"name\":\"System Teams\",\"description\":null,\"weight\":0,\"changed\":\"2024-08-02T21:29:47+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$bc\"}\nc0:{\"drupal_internal__target_id\":\"roles\"}\nbf:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":\"$c0\"}\nc2:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/vid?resourceVersion=id%3A71\"}\nc3:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/vid?resourceVersion=id%3A71\"}\nc1:{\"related\":\"$c2\",\"self\":\"$c3\"}\nbe:{\"data\":\"$bf\",\"links\":\"$c1\"}\nc6:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/revision_user?resourceVersion=id%3A71\"}\nc7:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/revision_user?resourceVersion=id%3A71\"}\nc5:{\"related\":\"$c6\",\"self\":\"$c7\"}\nc4:{\"data\":null,\"links\":\"$c5\"}\nce:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\ncd:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$ce\"}\ncc:{\"help\":\"$cd\"}\ncb:{\"links\":\"$cc\"}\nca:{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":\"$cb\"}\nc9:[\"$ca\"]\nd0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/parent?resourceVersion=id%3A71\"}\nd1:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/parent?resourceVersion=id%3A7"])</script><script>self.__next_f.push([1,"1\"}\ncf:{\"related\":\"$d0\",\"self\":\"$d1\"}\nc8:{\"data\":\"$c9\",\"links\":\"$cf\"}\nbd:{\"vid\":\"$be\",\"revision_user\":\"$c4\",\"parent\":\"$c8\"}\nb8:{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"links\":\"$b9\",\"attributes\":\"$bb\",\"relationships\":\"$bd\"}\nd4:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0?resourceVersion=id%3A16\"}\nd3:{\"self\":\"$d4\"}\nd6:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\nd5:{\"drupal_internal__tid\":16,\"drupal_internal__revision_id\":16,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:05:20+00:00\",\"status\":true,\"name\":\"CMS Policy \u0026 Guidance\",\"description\":null,\"weight\":2,\"changed\":\"2023-03-10T19:04:22+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$d6\"}\nda:{\"drupal_internal__target_id\":\"topics\"}\nd9:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"73f89dec-123f-4c8c-9a97-d025a2b0e5cf\",\"meta\":\"$da\"}\ndc:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/vid?resourceVersion=id%3A16\"}\ndd:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/relationships/vid?resourceVersion=id%3A16\"}\ndb:{\"related\":\"$dc\",\"self\":\"$dd\"}\nd8:{\"data\":\"$d9\",\"links\":\"$db\"}\ne0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/revision_user?resourceVersion=id%3A16\"}\ne1:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/relationships/revision_user?resourceVersion=id%3A16\"}\ndf:{\"related\":\"$e0\",\"self\":\"$e1\"}\nde:{\"data\":null,\"links\":\"$df\"}\ne8:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\ne7:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$e8\"}\ne6:{\"help\":\"$e7\"}\ne5:{\"links\":\"$e6\"}\ne4:{\"type\":\"taxonomy_term--topics\",\"id\":\"virtual\",\"meta\":\"$e5\"}\ne3:[\"$e4\"]\nea:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/parent?resourceVersion=id%3A1"])</script><script>self.__next_f.push([1,"6\"}\neb:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/relationships/parent?resourceVersion=id%3A16\"}\ne9:{\"related\":\"$ea\",\"self\":\"$eb\"}\ne2:{\"data\":\"$e3\",\"links\":\"$e9\"}\nd7:{\"vid\":\"$d8\",\"revision_user\":\"$de\",\"parent\":\"$e2\"}\nd2:{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"links\":\"$d3\",\"attributes\":\"$d5\",\"relationships\":\"$d7\"}\nee:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e?resourceVersion=id%3A19550\"}\ned:{\"self\":\"$ee\"}\nf0:[]\nf2:Tced,"])</script><script>self.__next_f.push([1,"\u003ch2\u003eWhat are the CMS Security and Privacy Handbooks?\u003c/h2\u003e\u003cp\u003eThe CMS Security and Privacy Handbooks help CMS staff and contractors to follow federal policies and standards that keep CMS information and systems safe. They provide practical guidance for implementing the requirements of the \u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS Information Systems Security and Privacy Policy (IS2P2)\u003c/a\u003e and the \u003ca href=\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eAcceptable Risk Safeguards (ARS)\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003ch3\u003eWhat authority do the Handbooks have?\u003c/h3\u003e\u003cp\u003eCMS has several levels of policy and guidance for the information security and privacy program:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePolicies and standards\u003c/strong\u003e, which are enterprise-level directives and the details for how they must be implemented. Our policies and standards are the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS Information System Security and Privacy Policy (IS2P2)\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS Acceptable Risk Safeguards (ARS)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProgram plans\u003c/strong\u003e, which explain how the high-level security and privacy programs at CMS uphold the policies and standards, laying out a roadmap for all ISPG activities. Our program plans include the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-program-plan\"\u003ePrivacy Program Plan\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-cyber-risk-management-plan-crmp\"\u003eCMS Cyber Risk Management Plan (CRMP)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProcedural handbooks\u003c/strong\u003e, which give practical guidance about how to implement the requirements found within the policies, standards, and program plans. Our procedural handbooks are the \u003ca href=\"https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks\"\u003eCMS Security and Privacy Handbooks\u003c/a\u003e – a go-to resource for anyone who is involved with the work of keeping CMS systems and data safe.\u003c/p\u003e\u003cp\u003eThe Handbooks are provided as \u003cstrong\u003ereliable guidance\u003c/strong\u003e approved by the CMS Chief Information Security Officer (CISO), who is responsible for implementing the agency-wide information security program. The Handbooks support the policies and standards that CMS uses to meet requirements from higher-level authorities such as the Department of\u0026nbsp; Health and Human Services (HHS).\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe Handbooks also provide \u003cstrong\u003estep-by-step instructions\u003c/strong\u003e for CMS security and privacy activities such as \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-impact-assessment-pia-handbook\"\u003ePrivacy Impact Assessment\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/policy-guidance/threat-modeling-handbook\"\u003eThreat Modeling\u003c/a\u003e, and more.\u003c/p\u003e\u003cp\u003eThese Handbooks do not supersede any applicable laws, existing labor management agreements, or higher-level agency directives or other governance documents. To learn more about the authorities, directives and laws that govern the CMS security and privacy program, see the CMS Information Security and Privacy Policy (IS2P2).\u003c/p\u003e"])</script><script>self.__next_f.push([1,"f3:Tced,"])</script><script>self.__next_f.push([1,"\u003ch2\u003eWhat are the CMS Security and Privacy Handbooks?\u003c/h2\u003e\u003cp\u003eThe CMS Security and Privacy Handbooks help CMS staff and contractors to follow federal policies and standards that keep CMS information and systems safe. They provide practical guidance for implementing the requirements of the \u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS Information Systems Security and Privacy Policy (IS2P2)\u003c/a\u003e and the \u003ca href=\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eAcceptable Risk Safeguards (ARS)\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003ch3\u003eWhat authority do the Handbooks have?\u003c/h3\u003e\u003cp\u003eCMS has several levels of policy and guidance for the information security and privacy program:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePolicies and standards\u003c/strong\u003e, which are enterprise-level directives and the details for how they must be implemented. Our policies and standards are the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS Information System Security and Privacy Policy (IS2P2)\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS Acceptable Risk Safeguards (ARS)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProgram plans\u003c/strong\u003e, which explain how the high-level security and privacy programs at CMS uphold the policies and standards, laying out a roadmap for all ISPG activities. Our program plans include the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-program-plan\"\u003ePrivacy Program Plan\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-cyber-risk-management-plan-crmp\"\u003eCMS Cyber Risk Management Plan (CRMP)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProcedural handbooks\u003c/strong\u003e, which give practical guidance about how to implement the requirements found within the policies, standards, and program plans. Our procedural handbooks are the \u003ca href=\"https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks\"\u003eCMS Security and Privacy Handbooks\u003c/a\u003e – a go-to resource for anyone who is involved with the work of keeping CMS systems and data safe.\u003c/p\u003e\u003cp\u003eThe Handbooks are provided as \u003cstrong\u003ereliable guidance\u003c/strong\u003e approved by the CMS Chief Information Security Officer (CISO), who is responsible for implementing the agency-wide information security program. The Handbooks support the policies and standards that CMS uses to meet requirements from higher-level authorities such as the Department of\u0026nbsp; Health and Human Services (HHS).\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe Handbooks also provide \u003cstrong\u003estep-by-step instructions\u003c/strong\u003e for CMS security and privacy activities such as \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-impact-assessment-pia-handbook\"\u003ePrivacy Impact Assessment\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/policy-guidance/threat-modeling-handbook\"\u003eThreat Modeling\u003c/a\u003e, and more.\u003c/p\u003e\u003cp\u003eThese Handbooks do not supersede any applicable laws, existing labor management agreements, or higher-level agency directives or other governance documents. To learn more about the authorities, directives and laws that govern the CMS security and privacy program, see the CMS Information Security and Privacy Policy (IS2P2).\u003c/p\u003e"])</script><script>self.__next_f.push([1,"f1:{\"value\":\"$f2\",\"format\":\"body_text\",\"processed\":\"$f3\"}\nef:{\"drupal_internal__id\":556,\"drupal_internal__revision_id\":19550,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-04T16:55:18+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_page_section\",\"behavior_settings\":\"$f0\",\"default_langcode\":true,\"revision_translation_affected\":true,\"field_text_block\":\"$f1\"}\nf7:{\"drupal_internal__target_id\":\"page_section\"}\nf6:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"57f3f40a-8120-4393-b881-a5758f9fb30d\",\"meta\":\"$f7\"}\nf9:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e/paragraph_type?resourceVersion=id%3A19550\"}\nfa:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e/relationships/paragraph_type?resourceVersion=id%3A19550\"}\nf8:{\"related\":\"$f9\",\"self\":\"$fa\"}\nf5:{\"data\":\"$f6\",\"links\":\"$f8\"}\nfd:{\"target_revision_id\":19549,\"drupal_internal__target_id\":3390}\nfc:{\"type\":\"paragraph--call_out_box\",\"id\":\"8b6ef8b3-acd0-47f9-8050-9c68b8c24ada\",\"meta\":\"$fd\"}\nff:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e/field_specialty_item?resourceVersion=id%3A19550\"}\n100:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e/relationships/field_specialty_item?resourceVersion=id%3A19550\"}\nfe:{\"related\":\"$ff\",\"self\":\"$100\"}\nfb:{\"data\":\"$fc\",\"links\":\"$fe\"}\nf4:{\"paragraph_type\":\"$f5\",\"field_specialty_item\":\"$fb\"}\nec:{\"type\":\"paragraph--page_section\",\"id\":\"6348291e-48d1-4a0e-9a57-ac86d40af43e\",\"links\":\"$ed\",\"attributes\":\"$ef\",\"relationships\":\"$f4\"}\n103:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22?resourceVersion=id%3A19551\"}\n102:{\"self\":\"$103\"}\n105:[]\n107:Td96,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eRisk Management Handbook (RMH) chapters\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe CMS Risk Management Handbook (RMH) chapters are a series of procedures that support CMS policies and standards, mapped to specific control families in the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-risk-management-framework-rmf\"\u003eNIST Risk Management Framework\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003eOver time, \u003cstrong\u003ethe RMH chapters will be modified and absorbed into the broader CMS Security and Privacy Handbooks\u003c/strong\u003e for a more flexible approach to procedural guidance – not dependent on specific security controls, but still covering all the topics needed to help CMS staff and contractors follow policies, standards, and best practices.\u003c/p\u003e\u003cp\u003eUse the links below to access the chapters of the Risk Management Handbook. Note that some chapters may not be listed here, as the RMH is evolving.\u003c/p\u003e\u003cul\u003e\u003cli\u003eAre you looking for\u0026nbsp;\u003cem\u003eRMH Chapter 1: Access Control\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-access-control-handbook\"\u003eCMS Access Control Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-2-awareness-and-training\"\u003eRMH Chapter 2: Awareness and Training\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eRMH Chapter 4: Assessment and Authorization\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\"\u003eRMH Chapter 5: Configuration Management\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 6: Contingency Planning\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-system-contingency-plan-iscp-handbook\"\u003eCMS Information System Contingency Plan (ISCP) Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\"\u003eRMH Chapter 8: Incident Response\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-9-maintenance-ma\"\u003eRMH Chapter 9: Maintenance\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 10: Media Protection\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-media-protection-mp-handbook\"\u003eCMS Media Protection Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-11-physical-environmental-protection\"\u003eRMH Chapter 11: Physical and Environmental Protection\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-12-security-privacy-planning-pl\"\u003eRMH Chapter 12: Security and Privacy Planning\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-13-personnel-security-ps\"\u003eRMH Chapter 13: Personnel Security\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-14-risk-assessment-ra\"\u003eRMH Chapter 14: Risk Assessment\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-15-system-services-acquisition\"\u003eRMH Chapter 15: System and Services Acquisition\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-16-system-communications-protection\"\u003eRMH Chapter 16: System and Communications Protection\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 19: Privacy Procedures\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-program-plan\"\u003ePrivacy Program Plan\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/ispg/privacy\"\u003ewhole collection of Privacy resources\u003c/a\u003e\u0026nbsp;here on the ISPG website.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"108:Td96,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eRisk Management Handbook (RMH) chapters\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe CMS Risk Management Handbook (RMH) chapters are a series of procedures that support CMS policies and standards, mapped to specific control families in the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-risk-management-framework-rmf\"\u003eNIST Risk Management Framework\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003eOver time, \u003cstrong\u003ethe RMH chapters will be modified and absorbed into the broader CMS Security and Privacy Handbooks\u003c/strong\u003e for a more flexible approach to procedural guidance – not dependent on specific security controls, but still covering all the topics needed to help CMS staff and contractors follow policies, standards, and best practices.\u003c/p\u003e\u003cp\u003eUse the links below to access the chapters of the Risk Management Handbook. Note that some chapters may not be listed here, as the RMH is evolving.\u003c/p\u003e\u003cul\u003e\u003cli\u003eAre you looking for\u0026nbsp;\u003cem\u003eRMH Chapter 1: Access Control\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-access-control-handbook\"\u003eCMS Access Control Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-2-awareness-and-training\"\u003eRMH Chapter 2: Awareness and Training\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eRMH Chapter 4: Assessment and Authorization\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\"\u003eRMH Chapter 5: Configuration Management\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 6: Contingency Planning\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-system-contingency-plan-iscp-handbook\"\u003eCMS Information System Contingency Plan (ISCP) Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\"\u003eRMH Chapter 8: Incident Response\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-9-maintenance-ma\"\u003eRMH Chapter 9: Maintenance\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 10: Media Protection\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-media-protection-mp-handbook\"\u003eCMS Media Protection Handbook\u003c/a\u003e.\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-11-physical-environmental-protection\"\u003eRMH Chapter 11: Physical and Environmental Protection\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-12-security-privacy-planning-pl\"\u003eRMH Chapter 12: Security and Privacy Planning\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-13-personnel-security-ps\"\u003eRMH Chapter 13: Personnel Security\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-14-risk-assessment-ra\"\u003eRMH Chapter 14: Risk Assessment\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-15-system-services-acquisition\"\u003eRMH Chapter 15: System and Services Acquisition\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/policy-guidance/risk-management-handbook-chapter-16-system-communications-protection\"\u003eRMH Chapter 16: System and Communications Protection\u003c/a\u003e\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAre you looking for \u003cem\u003eRMH Chapter 19: Privacy Procedures\u003c/em\u003e? See the new \u003ca href=\"https://security.cms.gov/policy-guidance/cms-privacy-program-plan\"\u003ePrivacy Program Plan\u003c/a\u003e and the \u003ca href=\"https://security.cms.gov/ispg/privacy\"\u003ewhole collection of Privacy resources\u003c/a\u003e\u0026nbsp;here on the ISPG website.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"106:{\"value\":\"$107\",\"format\":\"body_text\",\"processed\":\"$108\"}\n104:{\"drupal_internal__id\":1031,\"drupal_internal__revision_id\":19551,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-09T15:43:03+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_page_section\",\"behavior_settings\":\"$105\",\"default_langcode\":true,\"revision_translation_affected\":true,\"field_text_block\":\"$106\"}\n10c:{\"drupal_internal__target_id\":\"page_section\"}\n10b:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"57f3f40a-8120-4393-b881-a5758f9fb30d\",\"meta\":\"$10c\"}\n10e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22/paragraph_type?resourceVersion=id%3A19551\"}\n10f:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22/relationships/paragraph_type?resourceVersion=id%3A19551\"}\n10d:{\"related\":\"$10e\",\"self\":\"$10f\"}\n10a:{\"data\":\"$10b\",\"links\":\"$10d\"}\n112:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22/field_specialty_item?resourceVersion=id%3A19551\"}\n113:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22/relationships/field_specialty_item?resourceVersion=id%3A19551\"}\n111:{\"related\":\"$112\",\"self\":\"$113\"}\n110:{\"data\":null,\"links\":\"$111\"}\n109:{\"paragraph_type\":\"$10a\",\"field_specialty_item\":\"$110\"}\n101:{\"type\":\"paragraph--page_section\",\"id\":\"f5048b9a-b22a-4e67-abde-e964ff928b22\",\"links\":\"$102\",\"attributes\":\"$104\",\"relationships\":\"$109\"}\n116:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/call_out_box/8b6ef8b3-acd0-47f9-8050-9c68b8c24ada?resourceVersion=id%3A19549\"}\n115:{\"self\":\"$116\"}\n118:[]\n11a:[]\n119:{\"uri\":\"https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks\",\"title\":\"\",\"options\":\"$11a\",\"url\":\"https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks\"}\n11b:{\"value\":\"Using the Search function on the ISPG \\\"CyberGeek\\\" website, you can search and filter to fi"])</script><script>self.__next_f.push([1,"nd CMS Security and Privacy Handbooks on a variety of topics.\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eUsing the Search function on the ISPG \u0026quot;CyberGeek\u0026quot; website, you can search and filter to find CMS Security and Privacy Handbooks on a variety of topics.\u003c/p\u003e\\n\"}\n117:{\"drupal_internal__id\":3390,\"drupal_internal__revision_id\":19549,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-07-08T15:06:58+00:00\",\"parent_id\":\"556\",\"parent_type\":\"paragraph\",\"parent_field_name\":\"field_specialty_item\",\"behavior_settings\":\"$118\",\"default_langcode\":true,\"revision_translation_affected\":true,\"field_call_out_link\":\"$119\",\"field_call_out_link_text\":\"Go to the Handbooks\",\"field_call_out_text\":\"$11b\",\"field_header\":\"See all Security and Privacy Handbooks\"}\n11f:{\"drupal_internal__target_id\":\"call_out_box\"}\n11e:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"a1d0a205-c6c9-4816-b701-4763d05de8e8\",\"meta\":\"$11f\"}\n121:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/call_out_box/8b6ef8b3-acd0-47f9-8050-9c68b8c24ada/paragraph_type?resourceVersion=id%3A19549\"}\n122:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/call_out_box/8b6ef8b3-acd0-47f9-8050-9c68b8c24ada/relationships/paragraph_type?resourceVersion=id%3A19549\"}\n120:{\"related\":\"$121\",\"self\":\"$122\"}\n11d:{\"data\":\"$11e\",\"links\":\"$120\"}\n11c:{\"paragraph_type\":\"$11d\"}\n114:{\"type\":\"paragraph--call_out_box\",\"id\":\"8b6ef8b3-acd0-47f9-8050-9c68b8c24ada\",\"links\":\"$115\",\"attributes\":\"$117\",\"relationships\":\"$11c\"}\n125:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66?resourceVersion=id%3A19552\"}\n124:{\"self\":\"$125\"}\n127:[]\n126:{\"drupal_internal__id\":566,\"drupal_internal__revision_id\":19552,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-07T16:51:17+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$127\",\"default_langcode\":true,\"revision_translation_affected\":true}\n12b:{\"drupal_internal__target_id\":\"internal_link\"}\n12a:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313"])</script><script>self.__next_f.push([1,"f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$12b\"}\n12d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66/paragraph_type?resourceVersion=id%3A19552\"}\n12e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66/relationships/paragraph_type?resourceVersion=id%3A19552\"}\n12c:{\"related\":\"$12d\",\"self\":\"$12e\"}\n129:{\"data\":\"$12a\",\"links\":\"$12c\"}\n131:{\"drupal_internal__target_id\":1126}\n130:{\"type\":\"node--library\",\"id\":\"4c71fa83-e15c-4187-a479-696657ea5e15\",\"meta\":\"$131\"}\n133:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66/field_link?resourceVersion=id%3A19552\"}\n134:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66/relationships/field_link?resourceVersion=id%3A19552\"}\n132:{\"related\":\"$133\",\"self\":\"$134\"}\n12f:{\"data\":\"$130\",\"links\":\"$132\"}\n128:{\"paragraph_type\":\"$129\",\"field_link\":\"$12f\"}\n123:{\"type\":\"paragraph--internal_link\",\"id\":\"0f74c41a-2461-4cf5-b11e-ff7ce0b96f66\",\"links\":\"$124\",\"attributes\":\"$126\",\"relationships\":\"$128\"}\n137:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068?resourceVersion=id%3A19553\"}\n136:{\"self\":\"$137\"}\n139:[]\n138:{\"drupal_internal__id\":571,\"drupal_internal__revision_id\":19553,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-07T16:50:30+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$139\",\"default_langcode\":true,\"revision_translation_affected\":true}\n13d:{\"drupal_internal__target_id\":\"internal_link\"}\n13c:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$13d\"}\n13f:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068/paragraph_type?resourceVersion=id%3A19553\"}\n140:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068/relationships/parag"])</script><script>self.__next_f.push([1,"raph_type?resourceVersion=id%3A19553\"}\n13e:{\"related\":\"$13f\",\"self\":\"$140\"}\n13b:{\"data\":\"$13c\",\"links\":\"$13e\"}\n143:{\"drupal_internal__target_id\":421}\n142:{\"type\":\"node--library\",\"id\":\"ddb65a30-0e50-44c7-a6bd-084b9a7e6f06\",\"meta\":\"$143\"}\n145:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068/field_link?resourceVersion=id%3A19553\"}\n146:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068/relationships/field_link?resourceVersion=id%3A19553\"}\n144:{\"related\":\"$145\",\"self\":\"$146\"}\n141:{\"data\":\"$142\",\"links\":\"$144\"}\n13a:{\"paragraph_type\":\"$13b\",\"field_link\":\"$141\"}\n135:{\"type\":\"paragraph--internal_link\",\"id\":\"fe6656d7-9b88-4a4c-a27f-e41c610ab068\",\"links\":\"$136\",\"attributes\":\"$138\",\"relationships\":\"$13a\"}\n149:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b-9518-5400af425d7f?resourceVersion=id%3A19554\"}\n148:{\"self\":\"$149\"}\n14b:[]\n14a:{\"drupal_internal__id\":576,\"drupal_internal__revision_id\":19554,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-07T16:50:55+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$14b\",\"default_langcode\":true,\"revision_translation_affected\":true}\n14f:{\"drupal_internal__target_id\":\"internal_link\"}\n14e:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$14f\"}\n151:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b-9518-5400af425d7f/paragraph_type?resourceVersion=id%3A19554\"}\n152:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b-9518-5400af425d7f/relationships/paragraph_type?resourceVersion=id%3A19554\"}\n150:{\"related\":\"$151\",\"self\":\"$152\"}\n14d:{\"data\":\"$14e\",\"links\":\"$150\"}\n155:{\"drupal_internal__target_id\":621}\n154:{\"type\":\"node--library\",\"id\":\"4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e\",\"meta\":\"$155\"}\n157:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b"])</script><script>self.__next_f.push([1,"-9518-5400af425d7f/field_link?resourceVersion=id%3A19554\"}\n158:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b-9518-5400af425d7f/relationships/field_link?resourceVersion=id%3A19554\"}\n156:{\"related\":\"$157\",\"self\":\"$158\"}\n153:{\"data\":\"$154\",\"links\":\"$156\"}\n14c:{\"paragraph_type\":\"$14d\",\"field_link\":\"$153\"}\n147:{\"type\":\"paragraph--internal_link\",\"id\":\"80d4e83c-5a1f-466b-9518-5400af425d7f\",\"links\":\"$148\",\"attributes\":\"$14a\",\"relationships\":\"$14c\"}\n15b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f?resourceVersion=id%3A19555\"}\n15a:{\"self\":\"$15b\"}\n15d:[]\n15c:{\"drupal_internal__id\":2776,\"drupal_internal__revision_id\":19555,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-04-05T14:07:45+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$15d\",\"default_langcode\":true,\"revision_translation_affected\":true}\n161:{\"drupal_internal__target_id\":\"internal_link\"}\n160:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$161\"}\n163:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f/paragraph_type?resourceVersion=id%3A19555\"}\n164:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f/relationships/paragraph_type?resourceVersion=id%3A19555\"}\n162:{\"related\":\"$163\",\"self\":\"$164\"}\n15f:{\"data\":\"$160\",\"links\":\"$162\"}\n167:{\"drupal_internal__target_id\":401}\n166:{\"type\":\"node--library\",\"id\":\"cba2b00b-3f53-42bd-8a60-f175e1d47a0a\",\"meta\":\"$167\"}\n169:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f/field_link?resourceVersion=id%3A19555\"}\n16a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f/relationships/field_link?resourceVersion=id%3A19555\"}\n168:{\"related\":\"$169\",\"self\":\"$16a\"}\n165:{\"data\":\"$166\",\"links\":\"$168\"}\n15e:{\"paragraph_type\":\"$15f\",\"fi"])</script><script>self.__next_f.push([1,"eld_link\":\"$165\"}\n159:{\"type\":\"paragraph--internal_link\",\"id\":\"9967f006-5e08-4568-b636-63e8e8050a8f\",\"links\":\"$15a\",\"attributes\":\"$15c\",\"relationships\":\"$15e\"}\n16d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17?resourceVersion=id%3A19556\"}\n16c:{\"self\":\"$16d\"}\n16f:[]\n16e:{\"drupal_internal__id\":1871,\"drupal_internal__revision_id\":19556,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-15T19:23:49+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$16f\",\"default_langcode\":true,\"revision_translation_affected\":true}\n173:{\"drupal_internal__target_id\":\"internal_link\"}\n172:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$173\"}\n175:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17/paragraph_type?resourceVersion=id%3A19556\"}\n176:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17/relationships/paragraph_type?resourceVersion=id%3A19556\"}\n174:{\"related\":\"$175\",\"self\":\"$176\"}\n171:{\"data\":\"$172\",\"links\":\"$174\"}\n179:{\"drupal_internal__target_id\":1141}\n178:{\"type\":\"node--library\",\"id\":\"596fc706-aa93-4b33-84a6-e648cf6c563d\",\"meta\":\"$179\"}\n17b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17/field_link?resourceVersion=id%3A19556\"}\n17c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17/relationships/field_link?resourceVersion=id%3A19556\"}\n17a:{\"related\":\"$17b\",\"self\":\"$17c\"}\n177:{\"data\":\"$178\",\"links\":\"$17a\"}\n170:{\"paragraph_type\":\"$171\",\"field_link\":\"$177\"}\n16b:{\"type\":\"paragraph--internal_link\",\"id\":\"e0709a54-90c1-4f0d-b02a-5e8dce6acc17\",\"links\":\"$16c\",\"attributes\":\"$16e\",\"relationships\":\"$170\"}\n17f:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18?resourceVersion=id%3A19557\"}\n17e:{\"self\":\"$17f\"}\n181:[]\n"])</script><script>self.__next_f.push([1,"180:{\"drupal_internal__id\":3512,\"drupal_internal__revision_id\":19557,\"langcode\":\"en\",\"status\":true,\"created\":\"2024-07-02T15:20:38+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$181\",\"default_langcode\":true,\"revision_translation_affected\":true}\n185:{\"drupal_internal__target_id\":\"internal_link\"}\n184:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$185\"}\n187:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18/paragraph_type?resourceVersion=id%3A19557\"}\n188:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18/relationships/paragraph_type?resourceVersion=id%3A19557\"}\n186:{\"related\":\"$187\",\"self\":\"$188\"}\n183:{\"data\":\"$184\",\"links\":\"$186\"}\n18b:{\"drupal_internal__target_id\":366}\n18a:{\"type\":\"node--library\",\"id\":\"fa2107f3-5c24-458b-b589-6c85321f2015\",\"meta\":\"$18b\"}\n18d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18/field_link?resourceVersion=id%3A19557\"}\n18e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18/relationships/field_link?resourceVersion=id%3A19557\"}\n18c:{\"related\":\"$18d\",\"self\":\"$18e\"}\n189:{\"data\":\"$18a\",\"links\":\"$18c\"}\n182:{\"paragraph_type\":\"$183\",\"field_link\":\"$189\"}\n17d:{\"type\":\"paragraph--internal_link\",\"id\":\"9c79715c-bf72-4433-9d27-f6a64a297c18\",\"links\":\"$17e\",\"attributes\":\"$180\",\"relationships\":\"$182\"}\n191:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15?resourceVersion=id%3A6181\"}\n190:{\"self\":\"$191\"}\n193:{\"alias\":\"/policy-guidance/cms-access-control-handbook\",\"pid\":981,\"langcode\":\"en\"}\n195:T12d87,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccess is the ability to make use of any system resource. \u003ca href=\"https://csrc.nist.gov/glossary/term/access_control\"\u003eAccess Control (AC)\u003c/a\u003e is the process of granting or denying specific requests to:\u003c/p\u003e\u003col\u003e\u003cli\u003eObtain and use the information and related information processing services\u003c/li\u003e\u003cli\u003eEnter specific physical facilities (e.g., federal buildings, military establishments, border crossing entrances)\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAccess Control entails the regulation of who or what is allowed to access resources in an information system or network. As an important aspect of information security, access control helps to prevent unauthorized access to systems, services, and data.\u003c/p\u003e\u003cp\u003eAccess Control focuses on how the organization must limit system access to authorized users, to processes acting on behalf of authorized users, or to devices (including other systems), and how the organization must limit the types of transactions and functions that authorized users are permitted to conduct. Access Control can be implemented in various ways, including but not limited to the use of passwords, biometric authentication, and permissions assigned to specific users or groups. The level of access granted to an individual or a system may vary depending on their roles or responsibilities within an organization.\u003c/p\u003e\u003cp\u003eAccess control, a selective restriction of access to systems or data, consists of two main components: authentication and authorization. Authentication is the verification of the identity of a user, process, or device, and it is often the prerequisite to allowing access to resources in a system. Authorization, on the other hand, is the process of granting or denying specific requests:\u003c/p\u003e\u003col\u003e\u003cli\u003eFor obtaining and using information and related information processing services\u003c/li\u003e\u003cli\u003eTo enter specific physical facilities (e.g., Federal buildings, military establishments, and border crossing entrances)\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAuthentication and authorization are concerned with determining the allowed activities of legitimate users and mediating every attempt to access the resources in the system or an authorized entrance into a federal facility. The access must be based on the principle of \u003ca href=\"https://csrc.nist.gov/glossary/term/least_privilege\"\u003eleast privilege\u003c/a\u003e. In some systems, complete access is granted after successful authentication of the user, but most systems require more sophisticated and complex controls. In addition to the authentication mechanism (such as a password or token), access control is concerned with how authorizations are structured. In some cases, authorization may mirror the structure of the organization, while in others it may be based on the sensitivity level of various information resources with the roles and responsibilities of the user accessing those resources.\u003c/p\u003e\u003cp\u003eThe requirements for the use or the prohibitions against the use of various system resources also vary from one system to another. For example, some information may be available to all users, some may be available to specific groups or divisions, and some may be accessible to only a few individuals or groups across the agency. While users must have access to the specific information needed to perform their jobs, denial of access to non-job-related information may be enforced. It may also be important to control the type of access that is permitted (e.g., the ability for an average user to execute, but not change, system programs). These various types of access restrictions enforce policy, and ensure that unauthorized actions are not permitted.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePurpose\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe purpose of this document is to serve as a guide for managing access by providing background information and an overview of access control policies, procedures, and processes for restricted resources and data across the Centers for Medicare \u0026amp; Medicaid (CMS).\u003c/p\u003e\u003cp\u003eTo implement the security requirements for the Access Control (AC) family, as identified in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST Special Publication (SP) 800-53 Revision 5 \u003cem\u003eSecurity and Privacy Controls for Information Systems and Organizations\u003c/em\u003e\u003c/a\u003e, \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p\"\u003eHHS \u003cem\u003ePolicy for Information Security and Privacy Protection (IS2P)\u003c/em\u003e\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS\u003cem\u003e Information Systems Security and Privacy Policy (IS2P2)\u003c/em\u003e\u003c/a\u003e\u003cem\u003e, \u003c/em\u003eand the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS\u003cem\u003e Acceptable Risk Safeguards (ARS)\u003c/em\u003e\u003c/a\u003e\u003cem\u003e, \u003c/em\u003ethis manual also defines the rules around access to resources, and how access is allowed or denied by ensuring that only authorized personnel are granted access to critical information and resources while maintaining the security and confidentiality of sensitive information and Controlled Unclassified Information (CUI).\u003c/p\u003e\u003cp\u003eThis document is also intended to provide a consistent and secure approach to managing access to information and systems by serving as a reference for all CMS federal employees, contractors, and other authorized personnel. By following the processes outlined in this manual, CMS can minimize the risk of security breaches, data theft, and unauthorized access, thereby safeguarding the confidentiality, integrity, and availability of its systems and protecting the stakeholders.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eApplicability and scope\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eFederal information systems are required to incorporate information security controls to protect the systems supporting their operations and missions. CMS is required to ensure the adequate protection of its information systems and must meet a minimum level of information security.\u003c/p\u003e\u003cp\u003eFurther, the use of controls is mandatory for federal information systems in accordance with \u003ca href=\"http://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf\"\u003eOffice of Management and Budget (OMB) Circular A-130\u003c/a\u003e, and the provisions of the Federal Information Security Modernization Act \u003ca href=\"https://www.congress.gov/bill/113th-congress/senate-bill/2521\"\u003e[FISMA]\u003c/a\u003e of 2014, which requires the implementation of minimum controls to protect federal information and information systems. This program manual, along with the CMS \u003cem\u003eARS\u003c/em\u003e, satisfies the requirements of FISMA, and OMB Policies, among other laws, regulations, and policies, and will improve communication among stakeholders on how access to information systems or networks within the agency is managed.\u003c/p\u003e\u003cp\u003eTo this, the program manual applies to all CMS personnel or entities:\u003c/p\u003e\u003cul\u003e\u003cli\u003eConducting business for CMS\u003c/li\u003e\u003cli\u003eCollecting or maintaining information for CMS\u003c/li\u003e\u003cli\u003eUsing or operating information systems on behalf of CMS, whether directly or through contractual relationships.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe lists of CMS personnel or entities include, but are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eOrganizational components, centers, or offices\u003c/li\u003e\u003cli\u003eFederal employees, contractor personnel, interns, or other non-government employees operating on behalf of CMS.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis document is also applicable to all Information Technology (IT) resources, including network and computer hardware, software and applications, mobile devices, and telecommunication systems owned or operated by (or on behalf of) CMS.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRoles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePlease refer to the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2#roles-and-responsibilities\"\u003e\u003cem\u003eCMS IS2P2\u003c/em\u003e: Roles and Responsibilities\u003c/a\u003e and \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p#7.33\"\u003e\u003cem\u003eHHS Policy for Information Security and Privacy Protection (IS2P)\u003c/em\u003e Section 7 Roles and Responsibilities\u003c/a\u003e for the specific roles of CMS staff positions, contractors, or any entity operating on behalf of CMS. Further, the responsibilities related to the specific role(s) in the \u003cem\u003eCMS IS2P2:\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eSupervisors\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cem\u003eSystem/Network Administrators\u003c/em\u003e\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eor \u003cem\u003eHHS IS2P:\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eSection 7.33 (System Administrator)\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cem\u003eSection 7.37 (Supervisor)\u003c/em\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003efor roles supporting the AC control family are as follows:\u003c/p\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eSupervisors\u0026nbsp;\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eAuthorize and (or) approve the creation of new user accounts.\u003c/li\u003e\u003cli\u003eEnsure the access role is based on the principle of least privilege to ensure the user only has the authorized access rights to systems and information that is only enough to perform the duties described within their job description.\u003c/li\u003e\u003cli\u003eEnsure the user account is disabled and (or) removed when the employee separates from the position and no longer requires access. \u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eSystem Administrators [ADMIN]\u003c/strong\u003e\u003c/em\u003e\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e\u0026nbsp;\u003cbr\u003e(e.g., database administrators, network administrators, web administrators, and application administrators)\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsure that when performing administrator-type functions (e.g., as a privileged user), the ADMIN is logged on their privileged account only and their responsibilities are established to perform just those privileged functions with defined privileged commands and privileged processes.\u003c/li\u003e\u003cli\u003eFollow the established CMS system security protocols and processes as established in the \u003ca href=\"https://security.cms.gov/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e for onboarding new employees for new account creation, once the individual has completed all pre-required onboarding activities before account issuance (e.g., filing out required application for access forms and receiving the appropriate approvals, completing required security awareness and role-based training, completing any person proofing requirements, obtaining a required CMS-approved hard token credentials [PIV card, RSA token, etc.] for multi-factor authentication, etc.) or for any user requiring a modification to their account security credentials.\u003c/li\u003e\u003cli\u003eEnsure the account security credential(s) are issued to the appropriate authorized individual user.\u003c/li\u003e\u003cli\u003eEnsure all the security-related activities required are met to ensure the secure establishment and management of user accounts. (Refer to Account Management below).\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eCMS Access Control services and practices\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis section describes an overview of some of the CMS services and practices that assist in the discussion and the implementation of the AC family as outlined in the \u003cem\u003eCMS ARS \u003c/em\u003eand the \u003cem\u003eCMS IS2P2. \u003c/em\u003eThe information in this section provides some important considerations for implementing Access Control based on the mission and business requirements of CMS, its operational environments, and the assessments of organizational and system risks. The additional information contained in this section also explains the purpose of the control and the mechanisms to meet the control requirements.\u003c/p\u003e\u003cp\u003ePlease consult the CMS \u003cem\u003eARS \u003c/em\u003efor specific procedures.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccount management\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccount Management control is required to establish the requirements for managing CMS systems and user accounts throughout the account lifecycle. The Office of Information Technology (OIT) implements mechanisms that are responsible for all account management-related activities. These mechanisms help to ensure CMS personnel or entities have secure, authorized access to CMS business applications. The primary functions of an account management feature are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eRegistration\u003c/li\u003e\u003cli\u003eAuthentication\u003c/li\u003e\u003cli\u003eAuthorization\u003c/li\u003e\u003cli\u003eIdentity and User Account Lifecycle Management.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe account control mechanisms are also required to authorize and monitor the use of guest or anonymous accounts, and remove, disable, or otherwise secure unnecessary accounts.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for Account Management:\u003c/p\u003e\u003col\u003e\u003cli\u003eCMS information systems must have a documented Access Control procedure to document account life cycle activities. A description of all authorized system users, account access privileges, and other applicable account attributes must be documented.\u003c/li\u003e\u003cli\u003eAccount creation, changes, disabling, and retiring are requested using the channels documented in the applicable access control procedure or the system security and privacy plan.\u003c/li\u003e\u003cli\u003eThe following requirements are adhered to before creating, enabling, modifying, disabling, or removing accounts:\u003c/li\u003e\u003c/ol\u003e\u003cul\u003e\u003cli\u003eValid access authorization\u003c/li\u003e\u003cli\u003eIntended system usage\u003c/li\u003e\u003cli\u003eSatisfactory completion of mandatory training requirements (Security Awareness Training [SAT] in the Awareness and Training [AT] family of controls [and annually thereafter]; pre-access and role-based training within the prescribed timeframe), acknowledgment of \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eRules of Behavior for General Users\u003c/a\u003e, and signed request forms.\u003c/li\u003e\u003cli\u003eA valid justification must be supplied if access rights are above what is minimally necessary to perform the duties of the job.\u003c/li\u003e\u003cli\u003eList of functions required to perform job duties\u003c/li\u003e\u003cli\u003eAuthorization and approval from applicable information account managers as described in the system security and privacy plan.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp; \u0026nbsp;4. The Primary Information System Security Officer (P-ISSO) (or alternate) is tasked with:\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsuring access control policies and procedures are followed.\u003c/li\u003e\u003cli\u003eAuditing account management activities to ensure compliance.\u003c/li\u003e\u003cli\u003eReviewing access privileges to ensure all users have justifiable permissions.\u003c/li\u003e\u003cli\u003eEnforce account management lifecycle activities.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe \u003cem\u003eCMS ARS\u003c/em\u003e requires removing or disabling default user accounts, renaming active default user accounts, implementing a centralized control of user access administrator functions, regulating and defining the access provided to contractors, searchable automated account management results by \u003ca href=\"https://security.cms.gov/learn/cms-cybersecurity-integration-center-ccic\"\u003eCMS Cybersecurity Integration Center (CCIC)\u003c/a\u003e, and all raw security information/results from relevant automated tools must be available in an unaltered format to the CCIC.\u003c/p\u003e\u003cp\u003eAccount managers must be notified when a CMS system user is terminated or transferred, and the user’s associated account removed, disabled, revoked, or otherwise secured within a Mission/Business/System-defined timeframe, and not to exceed 30 days from the date of termination or transfer. Account managers must also be notified when there are changes in the user's system usage or need to know.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated system account management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAutomated System Account Management is required to manage, create, enable, modify, disable, revoked, retire, and remove CMS system account(s) when a user is terminated or transferred. CMS access control tools leverage the use of emails or text messaging to notify managers and users of account lifecycle events. These tools have automated capabilities to review user account activities and usage and report atypical behavior using email notifications.\u003c/p\u003e\u003cp\u003eCMS system administrators must be notified via automated email whenever a user account lifecycle event has occurred. Automated email mechanisms must be in place to support the management of system accounts. Additionally, users are emailed prior to password expiration and are allowed to make the necessary password changes.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated temporary and emergency account management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAutomated temporary and emergency account management is required to automatically remove or disable the access rights of temporary or emergency accounts after a predefined period after activation rather than at the convenience of the system administrator. Automatic removal or disabling of accounts provides a more consistent implementation.\u003c/p\u003e\u003cp\u003eCMS temporary and emergency accounts are managed in accordance with the system’s account management procedures or the security and privacy plan. These accounts are provisioned only when necessary and authorized, and they must be established with a fixed duration based on the need not to exceed the CMS parameter.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable accounts\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to automatically disable accounts that are expired, no longer associated with a user or individual, violate CMS policy, or have been inactive for a predefined period.\u0026nbsp;\u003c/p\u003e\u003cp\u003eFor an inactive account, a scheduled task reconciles the Last Login Date from the system database and locks the user account if the period reached its expiration date. Users who have not logged in during the inactivity period are marked as inactive and their accounts locked. The user will be notified at the next logon attempt that their account has been locked and can make use of the self-unlock feature or an IT Service Desk request for a user account reset.\u003c/p\u003e\u003cp\u003eAll these processes support the concepts of least privilege and least functionality that reduce the attack surface of systems.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated audit actions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS access control systems are required to utilize the capability to automatically produce event logs for system administrators to review for administrative actions. These may include account creation, modification, enabling, disabling, and removal actions for audit record review, analysis, and reporting. In addition to any other actions defined in the applicable system security and privacy plan.\u003c/p\u003e\u003cp\u003eCMS systems must be configured to log and audit the following account lifecycle events:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCreation\u003c/li\u003e\u003cli\u003eEnabling\u003c/li\u003e\u003cli\u003eModification\u003c/li\u003e\u003cli\u003eDisabling and;\u003c/li\u003e\u003cli\u003eRemoval (Retirement and Termination).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNotifications for these relevant and significant events are sent to the system administrators or managers as documented in the applicable security and privacy plan. Account actions in Active Directory (AD) are logged and exported to a Security Incident and Event Management (SIEM) tool where custom alerts are created, which notify appropriate individuals of these activities.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eInactivity logout\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eInactivity logout after a defined period reduces the risks of unauthorized access to CMS systems. This is accomplished by setting a lock on the system after 90 minutes of inactivity to prevent users from obtaining information from the display device while an authorized user is actively logged into the system or application. Users are also encouraged to lock their systems when leaving the vicinity and are required to log out at the end of a normal work period.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eUsage conditions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eClearly defined account usage conditions establish and describe the specific conditions or circumstances under which CMS system accounts can be used. These conditions help enforce the principle of least privilege, increase user accountability, and enable effective account monitoring. CMS defines these usage conditions for particular system accounts as necessary to provide adequate information protections and configure systems to enforce them.\u003c/p\u003e\u003cp\u003eThe following details the usage conditions that are set and must be met before access is granted to CMS systems:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS requires all users who have been provisioned a User ID to complete an initial and annual certification of access needs, as well as the security Computer Based Training (CBT) course. Access is revoked for users who have not complied with these requirements annually.\u003c/li\u003e\u003cli\u003eCMS users are required to accept the government warning displayed on the CMS warning banner before accessing CMS Government-Furnished Equipments (GFEs), CMS VPN connections, or CMS Virtual Desktop Infrastructure (VDI) using CITRIX Workspace connections. This warning banner is an acknowledgment of monitoring and usage restrictions.\u003c/li\u003e\u003cli\u003eAll users must complete all CMS system-related documentation including access request forms, \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eHHS rules of behavior\u003c/a\u003e for General Users, and any additional training required based on individuals with Significant Information Security Responsibilities (SISR), e.g., Role Based Training (RBT) for any user identified with significant information security and privacy responsibilities, as required in the applicable system security and privacy plan.\u003c/li\u003e\u003cli\u003eCMS users are prohibited from accessing systems from non-US locations during foreign travels without first obtaining official leadership approval. For more information on the approval process, review Chapter 10: Foreign Travel of the \u003cem\u003eCMS Physical Security Handbook\u003c/em\u003e.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAccount monitoring for atypical usage\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe administrative monitoring of activities associated with CMS system accounts is established to determine unusual and malicious use. CMS security teams monitor accounts for atypical usage that may include assessing systems at unusual days and times or from locations that are not consistent with the normal usage patterns of individuals, and for unusual information transfer volumes. Monitoring may also reveal rogue behavior by individuals or an attack in progress. There is coordination between CMS systems and the security teams through the CCIC to monitor system accounts and their usage and report to CMS incident response teams.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for monitoring user accounts for atypical usage.\u003c/p\u003e\u003cp\u003eCMS employs several security appliances and devices to assist with the ongoing monitoring of systems, as well as related system accounts, for atypical usage.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eFirewalls:\u003c/strong\u003e Network- and host-based firewalls are used to monitor traffic and generate daily reports covering the last 24 hours of activity.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity Information and Event Management (SIEM):\u003c/strong\u003e This solution is used to review logs generated from applications, databases, and servers for analysis by CMS security teams.\u003c/p\u003e\u003cp\u003eIn accordance with CMS information system Incident Response Plans, CMS CCIC should be notified immediately of potential security incidents upon discovery.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable accounts for high-risk individuals\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eDisabling the accounts for high-risk individuals reduces the risks posed by an insider threat that could adversely impact CMS IT assets, environment, operations, and individuals. Users who pose significant security or privacy risks include individuals for whom reliable evidence indicates either intention to use authorized access to a system to cause harm or through whom adversaries will cause harm.\u003c/p\u003e\u003cp\u003eDisabling accounts of high-risk individuals is a minimum requirement for the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior\u003c/a\u003e for Use of Information and IT Resources because of the possibility of abusing access privileges to sensitive information and CUI, including information protected under the Privacy Act.\u003c/p\u003e\u003cp\u003eAccount management activities must be expedited for the revocation of access for high-risk user accounts. Notification is sent to the appropriate security personnel as documented in the system security and privacy plan using the appropriate channels (email or phone). After being notified, the account must be disabled within a reasonable time frame not to exceed the CMS-established parameter from the time the high-risk account is identified.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccess enforcement\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccess control policies and the associated access enforcement mechanisms are employed to automatically control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the systems. These access control mechanisms must restrict access to any sensitive information, CUI or personally identifiable information (PII) and protected health information (PHI).\u003c/p\u003e\u003cp\u003eCMS systems are configured to enforce approved authorizations for logical access to information and system resources that support its mission and business functions, in accordance with applicable access control policies.\u003c/p\u003e\u003cp\u003eFurther, access enforcement mechanisms can be employed at the application and service level to provide increased information security and privacy. Assigned privileges and rules are used to allow logical access to systems, applications, and databases. These privileges are assigned during the account creation and modification account lifecycle.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eControlled release\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eControlled release of information ensures systems implement technical or procedural means to validate the controls implemented by any external systems before releasing information to them. All external systems or entities (i.e., departments, agencies, or commercial entities not managed by CMS) must provide controls that are commensurate with those implemented by CMS to protect the released information. The means used to determine the adequacy of the controls provided by the recipient systems may include conducting periodic assessments (inspections/tests), establishing agreements between CMS and external entities, or some other process. The adequacy of the implemented controls on those external systems ensures a consistent adjudication of the security and privacy policy that protects the information and individuals’ privacy.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eIndividual access\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS allow access to individuals that enable them to review personally identifiable information about them collected via legislative mandates and healthcare programs. Access helps individuals to develop an understanding of how their personally identifiable information is processed, handled, and disseminated to ensure their data is accurate and secure. Access mechanisms can include request forms and application interfaces. As stipulated by the Privacy Act, individual record access procedures are contained in systems of record notices (SORN) and the SORNs published on the Federal Register and CMS/HHS websites.\u003c/p\u003e\u003cp\u003eHowever, individual access to certain types of records contained in the HHS Exempt Systems of Records may be exempt, in full or in part, from certain requirements of the Privacy Act, based on rulemakings promulgated under subsection (j) or (k) of the Privacy Act (5 U.S.C. § 552a(j), (k)). Note that 5 U.S.C §. 552a(d)(5) excludes material compiled in reasonable anticipation of a civil action or proceeding from the Privacy Act's access requirement, in all systems of records, without the need for rulemaking.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eInformation flow enforcement\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eInformation flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) without regard to subsequent access to that information. Flow control restrictions may include blocking external traffic that claims to be from within CMS, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from CMS's internal web proxy server, and limiting information transfers between CMS and other external entities based on data structures and content.\u003c/p\u003e\u003cp\u003eTransferring information between CMS and other external entities may require an agreement specifying how the information flow is enforced using \u003ca href=\"https://security.cms.gov/learn/cms-interconnection-security-agreement-isa\"\u003einterconnection security agreements (ISA)\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cms-information-exchange-agreement-iea\"\u003einformation exchange security agreements\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cms-memorandum-understanding-mou\"\u003ememoranda of understanding or agreement (MOU/MOA)\u003c/a\u003e, service level agreements (SLA), or other exchange agreements (as defined in the applicable security and privacy plans).\u003c/p\u003e\u003cp\u003eInformation flow enforcement may also include prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regarding mechanisms to reassign security or privacy attributes and labels.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing information flow enforcement.\u003c/p\u003e\u003cp\u003eCMS uses a variety of methods and applications to enforce information flow with systems and between interconnected systems.\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CMS access control systems are configured to enforce approved authorizations within CMS information systems and other interconnections. For more information on interconnections and information sharing, please review AC-21 in the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e\u003cem\u003e.\u003c/em\u003e\u003c/li\u003e\u003cli\u003eVirtual Local Area Networks (VLANs) are used to provide environment and zone separation with firewall device control between each interconnected VLAN. Firewall rules are then configured to restrict information flows to only authorized users.\u003c/li\u003e\u003cli\u003eInterconnection between different server types within the CMS information system environment is controlled by network devices including firewalls. Rules are set up to allow traffic to authorized destination internet protocol (IP) addresses only.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eFlow control of encrypted information\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to prevent encrypted information from bypassing information flow control mechanisms by either blocking the flow of the encrypted information or terminating communications sessions that attempt to pass encrypted information. Flow control mechanisms may include content checking, security policy filters, and data type identifiers. The term encryption is extended to cover encoded data that are not recognized by the filtering mechanisms.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSeparation of duties\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSeparation of duties for CMS’s accounts is enforced to address the potential for abuse of authorized privileges and reduces the risk of malevolent activity without collusion. Each individual`s responsibilities and privileges within CMS`s environment are defined in a way that inhibits intentional or inadvertent unauthorized activity. Through the use of job codes, roles, and access rights, the workflows for authorization are separated in the CMS environment. A job code is a role that grants a group of users, access to defined resources. All ISSOs are required to ensure that these requirements are implemented effectively and meet the minimum control standards within the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e in their respective systems during authorization.\u003c/p\u003e\u003cp\u003eFurther, implementing separation of duties control reduces the risk of inappropriate access to CMS's sensitive information and CUI (e.g., separating employees that perform security and breach investigations from routine mission and business functions).\u003c/p\u003e\u003cp\u003eCMS Business owners control the access to their respective CMS systems. They create privileges that limit an individual's account access only to those systems for which there is a business need. Access rights are established while considering the separation of duties based on the following factors:\u003c/p\u003e\u003cul\u003e\u003cli\u003eDividing mission functions and information system support functions among different individuals and/or roles.\u003c/li\u003e\u003cli\u003eConducting information system support functions with different individuals (e.g., system management, programming, configuration management, quality assurance and testing, and network security).\u003c/li\u003e\u003cli\u003eEnsuring security personnel administering access control functions do not also administer approval or audit functions.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eLeast privilege\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS employs the principle of least privilege to ensure that its information system accounts are provisioned at privilege levels no higher than necessary to accomplish the mission/business functions. In other words, the system access privileges are only enough, i.e., at a minimum, for a user to perform their assigned duties as prescribed in their job descriptions. CMS systems are configured to prevent non-privileged accounts from having access to security or audit-related settings and controls. It is strictly prohibited to knowingly exceed authorized access according to the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eAt CMS, role-based access control is used to restrict access to system functions only to designated individuals. The restrictions must be based on the minimum necessary access required to complete specific system activities. These restrictions must be included in system-specific documentation, and are necessary to ensure that only authorized users are permitted access to files, directories, drives, workstations, servers, network shares, ports, protocols, and services that are expressly required for the performance of their job duties. Unnecessary access rights associated with services that are not required for the operation of the system should be disabled.\u003c/p\u003e\u003cp\u003eThe concept of least privilege aligns with the notion of limiting access to CMS's sensitive information and CUI to those individuals with a documented need to know in the performance of their job duties.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthorize access to security functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eSecurity functions in CMS are limited only to authorized personnel. Security functions include but are not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), configuring settings for events to be audited, and establishing intrusion detection parameters.\u003c/p\u003e\u003cp\u003eCMS personnel classified as privileged users, according to the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS \u003cem\u003eIS2P2\u003c/em\u003e\u003c/a\u003e, are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe following details the CMS-specific process for authorizing access to security functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAccess is granted based on the privileged role and approved job codes, with privileged functions restricted to individuals with administrative or security functionality requirements.\u003c/li\u003e\u003cli\u003eThe privileged account is restricted to privileged functions only and cannot be used to perform normal user (i.e., non-privileged accounts) functions concurrently.\u003c/li\u003e\u003cli\u003eApproved servers may use RBAC which is implemented using Active Directory (AD) group memberships. Non-privileged accounts have no access to servers.\u003c/li\u003e\u003cli\u003eSystem configurations and parameters are by group policy (GPO).\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eNon-privileged access for non-security functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe implementation of non-privileged access for nonsecurity functions limits security exposure or incidents that might occur when users perform operations from within privileged accounts or roles. CMS-privileged accounts or roles must be used only when necessary to perform system administration and security duties. Also, CMS systems must be configured to prevent non-privileged users from executing privileged functions.\u003c/p\u003e\u003cp\u003eCMS-privileged users with access to security functions are provisioned with and required to use their non-privileged accounts to perform duties that do not require that level of access. The separation of privileged and non-privileged accounts also prevents unintended or unauthorized loss, modification, or exposure. For example, a System Administrator (SYSADMIN) would have a separate account to perform SYSADMIN functions, and a typical USER account to perform normal user functions such as email, application access [Word Documents, Spreadsheets, Presentations, etc.], etc. The SYSADMIN cannot perform SYSADMIN functions under the typical USER account or role.\u003c/p\u003e\u003cp\u003eIn addition, the typical USER account or role cannot perform SYSADMIN-type functions such as administration/ management of the following: operating systems, network operations (telecommunications devices, firewalls, DMZ, servers, database administration, etc.), application servers, database servers, etc. In other words, any operation that would require Operating System (OS), ADMIN, or root-level access to perform ADMIN-type services or operations.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNetwork access to privileged commands\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS restricts the ability to perform privileged commands across the network connection as opposed to the local access on its systems. CMS limits network access to activities requiring elevated privileges to situations where there is a compelling operational need. For example, a compelling operational need may include routine administration (management) of remote security and infrastructure devices across a dedicated management network (see the \u003cem\u003eCMS Technical Reference Architecture [TRA]\u003c/em\u003e for additional information).\u003c/p\u003e\u003cp\u003eNetwork access to privileged commands is limited to specific roles listed as privileged users in \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p\"\u003e\u003cem\u003eCMS IS2P2\u003c/em\u003e\u003c/a\u003e. These roles are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators\u0026nbsp;\u003c/li\u003e\u003cli\u003eAdditional roles as documented in the System Security and Privacy Plan (SSPP).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS personnel are approved for such access by requesting the necessary roles or privileges. The process of requesting and approving these roles or privileges (as documented in the system security and privacy plan) acts as a control to ensure the privilege is being assigned to the right user.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrivileged accounts\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS limits who is authorized to perform administrative or security functions on its systems. These functions may include configuring access permissions, setting audit logs, and performing system management functions. This level of access needs to be limited because it further protects sensitive information and CUI from being comprised by reducing the number of individuals who possess unnecessary high privileges.\u003c/p\u003e\u003cp\u003ePrivileged accounts are limited only to specific roles that require the performance of privileged functions in the CMS environment. These roles are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators\u0026nbsp;\u003c/li\u003e\u003cli\u003eAdditional roles as documented in the SSPP.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS personnel are approved for such access through the appropriate account privileges. The process of requesting and approving these account privileges (as documented in the SSPP) acts as a control to ensure the privilege is being assigned to the right user.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eReview of user privileges\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIn CMS, certain assigned user privileges may change over time to reflect changes in the mission and business functions, environments of operation, technologies, or threats. A periodic review of all assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid. If the need cannot be revalidated, appropriate corrective actions must be taken to address it.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eLog use of privileged functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eLog the use of all privileged functions to ensure that there is accountability for all CMS system accounts with privileged functions because of the elevated permissions to access, and grant access, to sensitive information and CUI.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for logging the use of privileged functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS systems audit the use of privileged functions via logging user accounts that have the right to conduct privileged functions only on the system.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe audit logs must include a user account trail of privileged commands executed intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts.\u003c/li\u003e\u003cli\u003eThese logs are then audited and reviewed using a SIEM tool.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eProhibit non-privileged users from executing privileged functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eProhibit non-privileged users from executing privileged functions so that appropriate individuals have access to privileged functions only based on their roles and responsibilities. Non-privileged users may not have the same level of trust as privileged users. Privileged users have access beyond that of a non-privileged user, and as such, may have a greater ability to access sensitive information and CUI. Privileged accounts typically may have root-level access to the system at the operating system (OS) level and therefore “keys to the kingdom” level of access to all components or services of that system. For this reason, systems must have the ability to trace (audit) the actions of the user who initiated them and what actions were taken.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe assignment of privileged functions to user accounts should be based on the role and the level of responsibility of the user, while still accounting for the principle of least privilege. Privileged functions are assigned to a user account through approved roles or privileges and the approval process acts as a safeguard to ensure access is being provisioned to the right user, who have been appropriately authorized for the escalated privilege.\u0026nbsp;\u003c/p\u003e\u003cp\u003eUsers' accounts are set up to allow only the necessary functions authorized, thereby enforcing the principle of least privilege.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eUnsuccessful logon attempts\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded counteracts denial of service attacks and ensures that the user account is accessed only by the owner of that account. Automatic account lockouts are initiated by systems and are usually temporary and automatically released after a predetermined period as established by the CMS system administrators.\u003c/p\u003e\u003cp\u003eThe implementation standards contained in the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e are determined by the system’s risk categorization as stated below:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHigh:\u003c/strong\u003e Configure the information system to lock out the user account automatically after three (3) invalid login attempts during a 120-minute time window. Require the lockout to persist until released by an administrator.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eModerate:\u003c/strong\u003e Configure the information system to lock out the user account automatically after five (5) invalid login attempts during a 120-minute time window. Require the lockout to persist for a minimum of one (1) hour.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eLow:\u003c/strong\u003e Configure the information system to disable access for at least fifteen (15) minutes after five (5) invalid login attempts during a 120-minute time window.\u003c/p\u003e\u003cp\u003eCMS users will experience a lockout if they reach the maximum number of invalid login attempts. Users will be locked out indefinitely and must contact the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/Request%2520IT%2520Service.aspx\"\u003eCMS IT Service Desk\u003c/a\u003e or their system administrator to request their account to be unlocked.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSystem use notification\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS systems are configured to display an approved notification to be accepted by users before login. This notification provides appropriate security and privacy notifications as well as terms of use of the system. All CMS information systems are configured to display a system-use notification message before granting access. This is commonly referred to as a “System Warning Banner”.\u0026nbsp;\u003c/p\u003e\u003cp\u003eHHS has an established language approved for use as defined in the \u003cem\u003eCMS ARS AC-08 System Use Notification \u003c/em\u003econtrol. The system must use the HHS-approved warning banner text unless the system is collecting Federal Tax Information (FTI), then the \u003ca href=\"https://www.irs.gov/pub/irs-pdf/p1075.pdf\"\u003eIRS Publication 1075\u003c/a\u003e requires the system to use the approved text specified in Exhibit 8 Warning Banner Examples from the \u003cem\u003eIRS AC-08 System Use Notification\u003c/em\u003e control standard. The warning banner notification message must be displayed upon successful logon, obtaining an affirmation in the workflow from the user of their understanding and acceptance of the warning before gaining system access. This warning message notifies users that the CMS system is owned by the U.S. Government and describes conditions for access, acceptable use, and access limitations. The warning is presented at the secure gateway, and again at the system/device level. The approved warning/notification message should require forced user interaction and require the user to explicitly select the “I Accept” button before proceeding to log on to the system. The system should retain the notification message or banner on the screen until users take the explicit action(s) to log on to or further access the system.\u003c/p\u003e\u003cp\u003eThe warning banner language has very important legal implications for CMS and its system resources. Should content need to be added to this banner, submit the modified warning banner language to the CMS CIO for review and approval prior to implementation. If a system has character limitations related to the warning banner display, the CMS CIO can provide an abbreviated warning banner version. The \u003ca href=\"https://www.irs.gov/pub/irs-pdf/p1075.pdf\"\u003eIRS Publication 1075\u003c/a\u003e in Exhibit 8 Warning Banner Examples also has approved abbreviated warning banner versions available to use. If this banner is inconsistent with any directives, policies, regulations, or standards, notify the CMS CIO immediately.\u003c/p\u003e\u003cp\u003eAll systems and network devices under CMS control must prominently display the notice and consent banner immediately upon users’ authentication to the system, including, but not limited to, websites, web pages where substantial personal information from the public is collected, Secure File Transfer Protocol (SFTP), Secure Shell (SSH), or other services accessed.\u003c/p\u003e\u003cp\u003eThe \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003eprovides additional requirements for the content and the implementation of System Use Notifications as specified by the AC-08 System Use Notification control standard.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eConcurrent session control\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS defines and implements the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or any combination thereof. A session is defined as an encounter between an end-user interface device (e.g., computer, terminal, process) and an application, including a network logon. One user session is the time between starting the application and quitting or exiting the application. For example, if a user can use separate browsers to open concurrent sessions with the same user account and log out of any of the concurrent sessions to terminate the other sessions, safeguards must be implemented to counteract this type of action.\u003c/p\u003e\u003cp\u003eCMS limits network log-on sessions to one (1) user/network/application session at a time by implementing the appropriate configuration settings. However, if a concurrent session of more than one (1) is required for the system, it needs to be documented in the applicable SSPP and approved by the CMS Authorizing Official (AO) during the Authorized To Operate (ATO) approval process.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDevice lock\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eDevice locks are actions taken to prevent logical access to systems when a period of inactivity has been detected on a CMS user account. This control is configured to protect sensitive information and CUI from unauthorized access when CMS system users are away from their workstations for a CMS-defined period of inactivity. Identification and authentication requirements must be met for users to re-establish access to the system. Group Policy is used to configure the device lock requirements.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing device lock:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS information systems, along with GFE computers distributed to CMS Federal staff and contractors, are configured with a fifteen (15) minute device lock on the operating system. The user will be required to re-authenticate themselves to continue accessing CMS resources.\u003c/li\u003e\u003cli\u003eWindows and UNIX servers are configured to lock the application, after thirty (30) minutes of inactivity. The user will be required to re-authenticate themselves to continue accessing CMS resources.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePattern-hiding displays\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePattern-hiding displays conceal, via the device lock, information with a publicly viewable image. All CMS systems are configured to conceal information that is previously available on the display with a screen saver. Pattern-Hiding Displays mitigate against unauthorized viewing of any sensitive information and CUI, especially PII or PHI. This type of threat is commonly referred to as “shoulder surfing”.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing pattern-hiding displays:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe system conceals information previously available on the display with a screen saver built into the operating system of the GFE.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS users can make use of this display before leaving GFE computers unattended or concealing information from unauthorized personnel.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe login screen is only available by pressing CTRL-ALT-DEL.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eSession termination\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSession termination ensures that all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) continue after the session is terminated. The conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.\u003c/p\u003e\u003cp\u003eCMS systems are configured to terminate user login sessions after a certain period of inactivity. For systems-specific login sessions, the system must implement automatic session termination based on a predefined condition or trigger outlined in their respective system security and privacy plan (SSPP).\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePermitted actions without identification or authentication\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSome specific user actions are permitted on CMS systems without identification or authentication required. Systems may allow a limited number of user actions like access to CMS public websites or other publicly accessible CMS systems that do not contain any sensitive information and CUI, but only the information that is appropriate for public consumption.\u003c/p\u003e\u003cp\u003eAll CMS systems that are not intended to be utilized by the public require proper user account processes and authentication. Please refer to the \u003ca href=\"https://pages.nist.gov/800-63-4/\"\u003eNIST Special Publication (SP) 800-63\u003c/a\u003e series regarding Digital Identity Guidelines (NIST SP 800-63, SP 800-63A, SP 800-63B, SP 800-63C).\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRemote access\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eRemote access is access to CMS systems by users (or processes acting on behalf of users) that communicate through external networks (for example, the Internet or non-secure telecommunication pathways and protocols) via CMS-approved VPNs or CMS VDI via the CITRIX Workspace. The use of CMS-approved VPNs or VDI does not make the access non-remote. However, the use of VPNs or VDI, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) provides sufficient information security assurance to the organization that it can effectively treat such connections as safe internal networks. Remote access to CMS network resources is securely configured and must meet, as a minimum, the following security requirements for posture validation:\u003c/p\u003e\u003col\u003e\u003cli\u003eUp-to-date system patches\u003c/li\u003e\u003cli\u003eCurrent malware/anti-virus software with up-to-date patches\u003c/li\u003e\u003cli\u003eA host-based intrusion detection system(s)\u003c/li\u003e\u003cli\u003eDisable functionality that provides the capability for automatic execution of code and\u003c/li\u003e\u003cli\u003eEmploys CMS-required encryption which is the Federal Information Processing Standard (FIPS) 140-2 validated cryptographic module at a minimum.\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eThe following details the CMS-specific process for implementing the remote access control:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe system should utilize a CMS-approved VPN(s) or VDI to ensure the security of the sessions and the integrity of client-based applications.\u003c/li\u003e\u003cli\u003eCMS users are not allowed to access CMS systems remotely without a CMS-issued RSA hard token or \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-3.pdf\"\u003eFIPS 201\u003c/a\u003e PIV card, along with an approved EUA job code.\u003c/li\u003e\u003cli\u003eAccess to the secure CMS VPN or CMS VDI will authenticate the user account using the EUA job code.\u003c/li\u003e\u003cli\u003eThe VPN solution used by CMS also includes a Network Access Control (NAC) component that performs a security assessment and verifies the latest critical operating system patches and up-to-date malware/anti-virus signatures.\u0026nbsp;\u003c/li\u003e\u003cli\u003eIf the computer fails any one of these checks, it will be quarantined, i.e., preventing remote users from connecting to the CMS network with machines that aren't up to date with malware/anti-virus signatures or OS patch levels, and securing the computer by placing VPN login credentials into a secured area with limited or no access to the CMS network until those conditions are remediated. In the remediation process, CMS users are instructed to obtain required updates from Windows Software Update Service (WSUS) servers or other update servers.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS contractors will be notified that they will need to disconnect from the VPN and update their computers by downloading the latest Microsoft critical patches and/or antivirus signatures before access is granted.\u003c/li\u003e\u003cli\u003eRemote access for privileged functions must be permitted only for compelling operational needs, must be strictly controlled, and must be explicitly authorized, in writing, by the CMS AO, i.e., the CIO (Chief Information Officer) or his/her designated representative.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAdditional information on connecting to the CMS Network using an approved CMS VPN service can be found in the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/RemoteAccessSupport.aspx?PageView=Shared\u0026amp;InitialTabId=Ribbon.WebPartPage\u0026amp;VisibilityContext=WSSWebPartPage#Remote\"\u003eRemote Access Support\u003c/a\u003e. Additional information for CMS Federal Employees or contractors using the CMS VDI can be found at \u003ca href=\"https://vdildap.cms.gov/logon/CMS_VDI_HOW_TO_GUIDE.pdf\"\u003eCMS Employees and Contractors How-To-Guide VDI\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMonitoring and control\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to employ automated mechanisms and establish parameters that facilitate the monitoring and control of remote access. User activities are also monitored and audited to ensure compliance with CMS remote access policies, as applicable to each CMS information system. For more information on remote access, visit the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/RemoteAccessSupport.aspx?PageView=Shared\u0026amp;InitialTabId=Ribbon.WebPartPage\u0026amp;VisibilityContext=WSSWebPartPage#Remote\"\u003eCMS Remote Access Support\u003c/a\u003e website.\u003c/p\u003e\u003cp\u003eAn Intrusion Detection System (IDS) is deployed to protect and monitor the integrity of the systems. Continuous monitoring is also deployed by the CMS Information Security and Privacy Group (ISPG) to ensure compliance with CMS policies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eProtection of confidentiality and integrity using encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems shall implement cryptographic mechanisms to protect remote access sessions. All encryption solutions used throughout CMS must be \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf\"\u003eFIPS 140-3\u003c/a\u003e tested and validated. The confidentiality and integrity of remote sessions, sensitive information and CUI shall be protected with end-to-end encryption commensurate with the sensitivity level of the data.\u003c/p\u003e\u003cp\u003eSystems must utilize a CMS-approved secure VPN or VDI solution to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Every access to the CMS Secure VPN or VDI requires authentication using secure user system account credentials.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWhen applicable and available, sessions should be secured with FIPS 140-3 hardware security modules and FIPS 140-3 compliant algorithms.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManaged Access Control points\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS remote accesses must be routed through authorized and managed network access control points to protect the network connections. A Trusted Internet Connection (TIC) must be utilized for all external network connections.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing managed access control points:\u003c/p\u003e\u003cp\u003eAll systems must utilize CMS-approved secure VPN or VDI connections to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Administrative access should be limited to designated CMS-approved VPN or VDI solutions. Based on the designated VPN or VDI solution, configurations for firewall rules, Intrusion Detection and Prevention System policies, server policies, and active directory group policies as implemented in collaboration with AC control family requirements, will limit remote access.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrivileged commands and access\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe execution of privileged commands and access via remote access is restricted. Remote access for privileged commands and access should only be permitted if operational needs cannot otherwise be met via a direct connection in a secured access-controlled environment.\u003c/p\u003e\u003cp\u003eSystems should be configured to allow privileged user accounts to execute privileged commands to security-relevant information via remote access under special circumstances associated with the need to complete a task for critical operational needs. If a system opts to enable appropriate privileged commands via remote access, the rationale for the permission must be documented in the SSPP and approved via the CMS AO during the ATO approval process.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWireless access\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS monitors for unauthorized wireless access and prohibits the installation of wireless access points (WAP) in its systems. The Infrastructure and User Services Group (IUSG) are in charge of managing wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS information systems and prohibits the installation of WAP to systems unless explicitly authorized, in writing, by the CMS AO, i.e., the CMS CIO or the designated representative.\u003c/p\u003e\u003cp\u003eIf wireless access is authorized and approved by the AO during the ATO process, CMS establishes usage restrictions and configuration/connection requirements such as:\u003c/p\u003e\u003cul\u003e\u003cli\u003eFIPS 140-3 encryption protection is enabled\u003c/li\u003e\u003cli\u003eAccess points are placed in secure areas where physical access controls can be implemented, monitored, and audited\u003c/li\u003e\u003cli\u003eAccess points are shut down, i.e., powered off, when not in use (nights, weekends)\u003c/li\u003e\u003cli\u003eA stateful inspection firewall is implemented between the wireless network and the wired infrastructure; where a direct telecommunication wired connection is established\u003c/li\u003e\u003cli\u003eMedia Address Control (MAC) address authentication is utilized\u003c/li\u003e\u003cli\u003ePersonal firewalls are utilized on the endpoint device, e.g., laptop, and file sharing is disabled on all wireless clients\u003c/li\u003e\u003cli\u003eIntrusion detection agents are deployed on the wireless side of the firewall device\u003c/li\u003e\u003cli\u003eWireless activity is monitored and recorded, and the records are regularly reviewed\u003c/li\u003e\u003cli\u003eAdheres to \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Wireless-Acceptable-Use-Policy.pdf#search=cms%2520rules%2520of%2520behavior\"\u003eCMS Policy for Wireless Client Access\u003c/a\u003e and \u003ca href=\"https://www.hhs.gov/sites/default/files/standard_2009-0003_001s_-_ocio.DOC\"\u003eHHS Standard for IEEE 802.11 Wireless Local Area Network (WLAN)\u003c/a\u003e.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eRogue wireless devices, i.e., unauthorized WAPs, that are connected to the network can be detected by the wireless intrusion prevention system (WIPS). Any unauthorized WAP connected to the CMS internal network will be detected and locked out at the switch level (performing a port lock action on the switch IP address connection point) and then followed up as a potential security incident using the CMS Incident Response Process. For additional information on how to connect an approved wireless connection to CMS, please refer to the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Wireless-Network-Employee-Connection-Guide.pdf\"\u003eCMS Wireless Network Connection Guide\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthentication and encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems are protected against wireless networking capabilities by using authentication and the encryption of both users and devices. Wireless networking capabilities represent a significant potential vulnerability that can be exploited by adversaries.\u003c/p\u003e\u003cp\u003eThe CMS Baltimore Data Center Group (BDCG) manages the wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS systems and prohibits the installation of WAP devices to systems unless explicitly authorized, in writing, by the CMS AO, i.e., the CMS CIO or the designated representative. For more information on Authentication and Encryption, please refer to the System and Communications Protection (SC) and the Identification and Authentication (IA) Controls of the \u003cem\u003eCMS ARS\u003c/em\u003e.\u003c/p\u003e\u003cp\u003eAll wireless access points are configured to authenticate users and devices before access is granted. Also, all WLAN components use FIPS 140-3 approved cryptographic algorithms to protect the confidentiality and integrity of WLAN communications.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable wireless networking\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll wireless network capabilities embedded within CMS systems components must be disabled before issuance and deployment. Disabling all the wireless capabilities when not needed for essential CMS missions or functions can reduce susceptibility to threats by adversaries involving wireless technologies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRestrict configurations by users\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccess enforcement mechanisms are employed to restrict access to configure wireless networking capability only to selected and authorized users. Only CMS-approved and authorized users should be allowed to configure network capabilities. The responsibility of securing the CMS wireless network should rest in the hands of network administrators with system administrator (SYSADMIN) type accounts, that only allow SYSADMIN type commands to be performed under this type of SYSADMIN role.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing restrictions on access to wireless configurations.\u003c/p\u003e\u003col\u003e\u003cli\u003eCMS restricts access to wireless networking configurations only to the authorized role of a network administrator.\u003c/li\u003e\u003cli\u003eWireless networking capabilities are also confined within CMS boundaries.\u003c/li\u003e\u003c/ol\u003e\u003ch2\u003e\u003cstrong\u003eAntennas and transmission power levels\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS limits the unauthorized use of wireless communications outside of CMS-controlled boundaries. Radio antennas and transmission power levels must be calibrated to reduce the probability that usable signals can be intercepted by unauthorized users. Network traffic must be continuously monitored within CMS boundaries to detect and respond to intrusion and network misuse.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccess Control for mobile devices\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAll CMS-controlled mobile devices, including when such devices are outside of the CMS-controlled areas, must abide by the established configuration requirements, connection requirements, and implementation guidance in the CMS ARS when connected to the CMS environment.\u003c/p\u003e\u003cp\u003eCMS network administrators must set usage restrictions, configuration, and connection requirements for all mobile devices. The \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Mobile-Device-Guidance.pdf#search=CMS%2520Guidance%2520for%2520Government%2520Furnished%2520Mobile%2520Devices\"\u003eCMS Guidance for Government Furnished Mobile Devices\u003c/a\u003e provides information on the responsible use of CMS-issued mobile devices.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing access control requirements for mobile devices:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAll CMS-issued laptops utilize full disk encryption software that is FIPS 140-3 validated\u003c/li\u003e\u003cli\u003eCMS-procured removable storage media are configured for use by the contracted maintainer and use CMS-approved encryption for the storage of information\u003c/li\u003e\u003cli\u003eAny non-GFE equipment being connected internally to the network requires a fully signed \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eRules of Behavior for General Users\u003c/a\u003e form which details CMS' Operational Division (OpDiv) security responsibilities relative to the equipment being connected, along with prior approval from the CMS AO during the ATO process. The document also details the responsibilities the requester will fulfill or face possible disciplinary and/or non-disciplinary actions. Please refer to the HHS RoB, Section 6.3 Non-compliance for a list of potential adverse actions that may be taken against a user for non-compliance.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eGFE equipment may be connected remotely via VPN (using the established VPN for the Contractors' process). VPN authentication involves remote NAC checks that ensure the integrity of the system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFull device or container-based encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS-issued mobile devices must be encrypted using full device or container-based encryption mechanisms to protect the confidentiality and integrity of the data and information contained. Container-based encryption provides a more fine-grained approach to data and information encryption on mobile devices, including encrypting selected data structures such as files, records, or fields. Since mobile devices are more likely to be lost or stolen, sensitive information on a mobile device(s) is more vulnerable to unauthorized disclosures and encryption reduces this vulnerability.\u003c/p\u003e\u003cp\u003eAt CMS, FIPS 140-3 encryption mechanisms are used to protect the confidentiality and integrity of information on CMS-issued mobile devices. CMS utilizes media and port protection software to encrypt removable media endpoint devices.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eUse of external systems\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS employs mechanisms that prohibit the use of external devices to access the systems within the network without a formal approval process. CMS complies with the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e, which strictly prohibits the use of personal devices to conduct CMS-related business without written and approved authorization by the CMS AO under the ATO approval process.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for the use of external information systems control requirements:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS prohibits the use of external systems without explicit written approval from the AO.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS does not allow the use of external systems that are not approved and do not meet CMS security requirements. If approval is granted, the recipient verifies the terms and conditions, ensures the required controls are implemented for the identified FIPS 199 system categorization to mitigate the associated risks, limits user access accordingly, and documents the control implementations in the SSPP.\u003c/li\u003e\u003cli\u003eAccess to PII from external systems (including, but not limited to, personally owned information systems/devices) is reinforced by a binding agreement to terms and conditions of the CMS’s privacy requirements to ensure awareness and accountability of both parties under the Interconnection Security Agreement approval process.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eLimits on authorized use\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS ensures that only authorized users are permitted to use external systems to access its systems, and these systems must have the necessary security configurations implemented before access is granted. These necessary security requirements are implemented and the CMS access control policies regarding the use of external systems are enforced.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for limiting the authorized use of external information systems:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS does not permit the use of external systems that are not approved and do not meet the CMS security requirements for accessing CMS systems per the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eExternal systems can only access CMS systems using approved VPN or VDI access and firewall/security verification software, which must be installed on each machine. This applies to federal employees and contractor personnel utilizing CMS GFE (laptop or desktop) only or approved corporate-issued computers per the contract.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePortable storage devices — restricted use\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS limits the use of its controlled-portable storage devices in external systems. Conditions of use or restrictions on these devices should be documented and configured by network administrators.\u003c/p\u003e\u003cp\u003eCMS has configured CMS-issued portable and mobile devices to meet federal requirements. CMS has provided several control implementations that support and manage how its information is used within portable storage devices. These include a policy to incorporate a methodology for protecting the information and the rules used to manage the information while in transit. For more information, review the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/StorageDeviceandEncryption.aspx\"\u003eCMS Storage Device and Encryption\u003c/a\u003e website.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eInformation sharing\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eInformation sharing control puts restrictions on CMS-sensitive information and CUI, such as personally identifiable information (PII), contract-sensitive information, proprietary information, and classified information related to special access programs or compartments, based on a formal or administrative risk-based determination. Depending on the information-sharing circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program/compartment.\u003c/p\u003e\u003cp\u003eGuidance for information sharing between CMS and other organizations is specified in the CMS Privacy Handbook. The document specifies the requirements for information sharing in the following documents:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-interconnection-security-agreement-isa\"\u003eInterconnection Security Agreement (ISA):\u003c/a\u003e System interconnections are defined within CFACTS and require a supporting “signed” ISA between CMS and non-CMS organizations as part of the SSP/ATO process.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-memorandum-understanding-mou\"\u003eMemorandum of Understanding (MOU):\u003c/a\u003e Defines the relationship of two or more federal partners that enter into a joint project or collaboration in which they each contribute their resources.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-data-use-agreement-dua\"\u003eData Use Agreement (DUA):\u003c/a\u003e 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.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-information-exchange-agreement-iea\"\u003eInformation Exchange Agreements (IEA):\u003c/a\u003e Is needed when Personally Identifiable Information (PII) needs to be shared externally, and that will not have an adverse impact on the beneficiary.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-computer-matching-agreement-cma\"\u003eComputer Matching Agreements (CMA):\u003c/a\u003e A written agreement establishing the conditions, safeguards, and procedures under which a federal agency agrees to disclose data with another federal or state agency when there is a computerized comparison of two or more automated Systems of Records (SORs).\u003c/li\u003e\u003cli\u003eOther forms of documented agreements required for different situations.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor additional guidance related to the above agreements and documents, please review the Privacy Handbook. The ISSO is responsible for developing and managing any agreement utilized for information sharing and should coordinate with the appropriate Data Guardian and Privacy Advisor.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePublicly accessible content\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePer applicable laws, executive orders, directives, policies, regulations, standards, and guidelines, the general public is not authorized to access non-public information, such as information protected under the Privacy Act information (e.g., PII/PHI), CMS sensitive information (e.g., data with a federal information classification standard, For Official Use Only [FOUO], or Controlled Unclassified Information [CUI]), and CMS proprietary information (e.g., proprietary acquisition data). This control addresses systems that are controlled by CMS and are accessible to the public, typically without requiring identification or authentication.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for adhering to requirements for publicly accessible content:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNetwork Connections\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eCMS Website Owners/Administrators are charged with limiting the connections to publicly available CMS websites and web services to approved secure protocols and adhering to Hypertext Transfer Protocol (HTTP) Strict Transport Security (HSTS) practices.\u003c/p\u003e\u003cul\u003e\u003cli\u003eAlthough general public access to the CMS internal network is not allowed, CMS websites are accessible by the public and protected by several Private Internet Exchange (PIX) firewalls\u003c/li\u003e\u003cli\u003eOutbound internet connections from CMS users are protected by Application Intelligence (NG AI) firewalls.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003ePublic Content\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CMS system personnel should reach out to the CMS Information Security and Privacy Group (ISPG) to review the proposed content of information on a publicly accessible system (including a public website) before posting or publication to ensure that nonpublic information is not included.\u003c/li\u003e\u003cli\u003eThe frequency of the review will be commensurate with the frequency information is posted. Whenever new information is being considered to be uploaded to a site, it should trigger a review process to ascertain it complies with CMS policy.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe system should consult the ISPG for clarification as to if the information is suitable for public accessibility and publication.\u003c/p\u003e"])</script><script>self.__next_f.push([1,"196:T12d87,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccess is the ability to make use of any system resource. \u003ca href=\"https://csrc.nist.gov/glossary/term/access_control\"\u003eAccess Control (AC)\u003c/a\u003e is the process of granting or denying specific requests to:\u003c/p\u003e\u003col\u003e\u003cli\u003eObtain and use the information and related information processing services\u003c/li\u003e\u003cli\u003eEnter specific physical facilities (e.g., federal buildings, military establishments, border crossing entrances)\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAccess Control entails the regulation of who or what is allowed to access resources in an information system or network. As an important aspect of information security, access control helps to prevent unauthorized access to systems, services, and data.\u003c/p\u003e\u003cp\u003eAccess Control focuses on how the organization must limit system access to authorized users, to processes acting on behalf of authorized users, or to devices (including other systems), and how the organization must limit the types of transactions and functions that authorized users are permitted to conduct. Access Control can be implemented in various ways, including but not limited to the use of passwords, biometric authentication, and permissions assigned to specific users or groups. The level of access granted to an individual or a system may vary depending on their roles or responsibilities within an organization.\u003c/p\u003e\u003cp\u003eAccess control, a selective restriction of access to systems or data, consists of two main components: authentication and authorization. Authentication is the verification of the identity of a user, process, or device, and it is often the prerequisite to allowing access to resources in a system. Authorization, on the other hand, is the process of granting or denying specific requests:\u003c/p\u003e\u003col\u003e\u003cli\u003eFor obtaining and using information and related information processing services\u003c/li\u003e\u003cli\u003eTo enter specific physical facilities (e.g., Federal buildings, military establishments, and border crossing entrances)\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAuthentication and authorization are concerned with determining the allowed activities of legitimate users and mediating every attempt to access the resources in the system or an authorized entrance into a federal facility. The access must be based on the principle of \u003ca href=\"https://csrc.nist.gov/glossary/term/least_privilege\"\u003eleast privilege\u003c/a\u003e. In some systems, complete access is granted after successful authentication of the user, but most systems require more sophisticated and complex controls. In addition to the authentication mechanism (such as a password or token), access control is concerned with how authorizations are structured. In some cases, authorization may mirror the structure of the organization, while in others it may be based on the sensitivity level of various information resources with the roles and responsibilities of the user accessing those resources.\u003c/p\u003e\u003cp\u003eThe requirements for the use or the prohibitions against the use of various system resources also vary from one system to another. For example, some information may be available to all users, some may be available to specific groups or divisions, and some may be accessible to only a few individuals or groups across the agency. While users must have access to the specific information needed to perform their jobs, denial of access to non-job-related information may be enforced. It may also be important to control the type of access that is permitted (e.g., the ability for an average user to execute, but not change, system programs). These various types of access restrictions enforce policy, and ensure that unauthorized actions are not permitted.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePurpose\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe purpose of this document is to serve as a guide for managing access by providing background information and an overview of access control policies, procedures, and processes for restricted resources and data across the Centers for Medicare \u0026amp; Medicaid (CMS).\u003c/p\u003e\u003cp\u003eTo implement the security requirements for the Access Control (AC) family, as identified in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST Special Publication (SP) 800-53 Revision 5 \u003cem\u003eSecurity and Privacy Controls for Information Systems and Organizations\u003c/em\u003e\u003c/a\u003e, \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p\"\u003eHHS \u003cem\u003ePolicy for Information Security and Privacy Protection (IS2P)\u003c/em\u003e\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS\u003cem\u003e Information Systems Security and Privacy Policy (IS2P2)\u003c/em\u003e\u003c/a\u003e\u003cem\u003e, \u003c/em\u003eand the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS\u003cem\u003e Acceptable Risk Safeguards (ARS)\u003c/em\u003e\u003c/a\u003e\u003cem\u003e, \u003c/em\u003ethis manual also defines the rules around access to resources, and how access is allowed or denied by ensuring that only authorized personnel are granted access to critical information and resources while maintaining the security and confidentiality of sensitive information and Controlled Unclassified Information (CUI).\u003c/p\u003e\u003cp\u003eThis document is also intended to provide a consistent and secure approach to managing access to information and systems by serving as a reference for all CMS federal employees, contractors, and other authorized personnel. By following the processes outlined in this manual, CMS can minimize the risk of security breaches, data theft, and unauthorized access, thereby safeguarding the confidentiality, integrity, and availability of its systems and protecting the stakeholders.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eApplicability and scope\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eFederal information systems are required to incorporate information security controls to protect the systems supporting their operations and missions. CMS is required to ensure the adequate protection of its information systems and must meet a minimum level of information security.\u003c/p\u003e\u003cp\u003eFurther, the use of controls is mandatory for federal information systems in accordance with \u003ca href=\"http://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf\"\u003eOffice of Management and Budget (OMB) Circular A-130\u003c/a\u003e, and the provisions of the Federal Information Security Modernization Act \u003ca href=\"https://www.congress.gov/bill/113th-congress/senate-bill/2521\"\u003e[FISMA]\u003c/a\u003e of 2014, which requires the implementation of minimum controls to protect federal information and information systems. This program manual, along with the CMS \u003cem\u003eARS\u003c/em\u003e, satisfies the requirements of FISMA, and OMB Policies, among other laws, regulations, and policies, and will improve communication among stakeholders on how access to information systems or networks within the agency is managed.\u003c/p\u003e\u003cp\u003eTo this, the program manual applies to all CMS personnel or entities:\u003c/p\u003e\u003cul\u003e\u003cli\u003eConducting business for CMS\u003c/li\u003e\u003cli\u003eCollecting or maintaining information for CMS\u003c/li\u003e\u003cli\u003eUsing or operating information systems on behalf of CMS, whether directly or through contractual relationships.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe lists of CMS personnel or entities include, but are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eOrganizational components, centers, or offices\u003c/li\u003e\u003cli\u003eFederal employees, contractor personnel, interns, or other non-government employees operating on behalf of CMS.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis document is also applicable to all Information Technology (IT) resources, including network and computer hardware, software and applications, mobile devices, and telecommunication systems owned or operated by (or on behalf of) CMS.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRoles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePlease refer to the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2#roles-and-responsibilities\"\u003e\u003cem\u003eCMS IS2P2\u003c/em\u003e: Roles and Responsibilities\u003c/a\u003e and \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p#7.33\"\u003e\u003cem\u003eHHS Policy for Information Security and Privacy Protection (IS2P)\u003c/em\u003e Section 7 Roles and Responsibilities\u003c/a\u003e for the specific roles of CMS staff positions, contractors, or any entity operating on behalf of CMS. Further, the responsibilities related to the specific role(s) in the \u003cem\u003eCMS IS2P2:\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eSupervisors\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cem\u003eSystem/Network Administrators\u003c/em\u003e\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eor \u003cem\u003eHHS IS2P:\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eSection 7.33 (System Administrator)\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cem\u003eSection 7.37 (Supervisor)\u003c/em\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003efor roles supporting the AC control family are as follows:\u003c/p\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eSupervisors\u0026nbsp;\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eAuthorize and (or) approve the creation of new user accounts.\u003c/li\u003e\u003cli\u003eEnsure the access role is based on the principle of least privilege to ensure the user only has the authorized access rights to systems and information that is only enough to perform the duties described within their job description.\u003c/li\u003e\u003cli\u003eEnsure the user account is disabled and (or) removed when the employee separates from the position and no longer requires access. \u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eSystem Administrators [ADMIN]\u003c/strong\u003e\u003c/em\u003e\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e\u0026nbsp;\u003cbr\u003e(e.g., database administrators, network administrators, web administrators, and application administrators)\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsure that when performing administrator-type functions (e.g., as a privileged user), the ADMIN is logged on their privileged account only and their responsibilities are established to perform just those privileged functions with defined privileged commands and privileged processes.\u003c/li\u003e\u003cli\u003eFollow the established CMS system security protocols and processes as established in the \u003ca href=\"https://security.cms.gov/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e for onboarding new employees for new account creation, once the individual has completed all pre-required onboarding activities before account issuance (e.g., filing out required application for access forms and receiving the appropriate approvals, completing required security awareness and role-based training, completing any person proofing requirements, obtaining a required CMS-approved hard token credentials [PIV card, RSA token, etc.] for multi-factor authentication, etc.) or for any user requiring a modification to their account security credentials.\u003c/li\u003e\u003cli\u003eEnsure the account security credential(s) are issued to the appropriate authorized individual user.\u003c/li\u003e\u003cli\u003eEnsure all the security-related activities required are met to ensure the secure establishment and management of user accounts. (Refer to Account Management below).\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eCMS Access Control services and practices\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis section describes an overview of some of the CMS services and practices that assist in the discussion and the implementation of the AC family as outlined in the \u003cem\u003eCMS ARS \u003c/em\u003eand the \u003cem\u003eCMS IS2P2. \u003c/em\u003eThe information in this section provides some important considerations for implementing Access Control based on the mission and business requirements of CMS, its operational environments, and the assessments of organizational and system risks. The additional information contained in this section also explains the purpose of the control and the mechanisms to meet the control requirements.\u003c/p\u003e\u003cp\u003ePlease consult the CMS \u003cem\u003eARS \u003c/em\u003efor specific procedures.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccount management\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccount Management control is required to establish the requirements for managing CMS systems and user accounts throughout the account lifecycle. The Office of Information Technology (OIT) implements mechanisms that are responsible for all account management-related activities. These mechanisms help to ensure CMS personnel or entities have secure, authorized access to CMS business applications. The primary functions of an account management feature are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eRegistration\u003c/li\u003e\u003cli\u003eAuthentication\u003c/li\u003e\u003cli\u003eAuthorization\u003c/li\u003e\u003cli\u003eIdentity and User Account Lifecycle Management.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe account control mechanisms are also required to authorize and monitor the use of guest or anonymous accounts, and remove, disable, or otherwise secure unnecessary accounts.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for Account Management:\u003c/p\u003e\u003col\u003e\u003cli\u003eCMS information systems must have a documented Access Control procedure to document account life cycle activities. A description of all authorized system users, account access privileges, and other applicable account attributes must be documented.\u003c/li\u003e\u003cli\u003eAccount creation, changes, disabling, and retiring are requested using the channels documented in the applicable access control procedure or the system security and privacy plan.\u003c/li\u003e\u003cli\u003eThe following requirements are adhered to before creating, enabling, modifying, disabling, or removing accounts:\u003c/li\u003e\u003c/ol\u003e\u003cul\u003e\u003cli\u003eValid access authorization\u003c/li\u003e\u003cli\u003eIntended system usage\u003c/li\u003e\u003cli\u003eSatisfactory completion of mandatory training requirements (Security Awareness Training [SAT] in the Awareness and Training [AT] family of controls [and annually thereafter]; pre-access and role-based training within the prescribed timeframe), acknowledgment of \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eRules of Behavior for General Users\u003c/a\u003e, and signed request forms.\u003c/li\u003e\u003cli\u003eA valid justification must be supplied if access rights are above what is minimally necessary to perform the duties of the job.\u003c/li\u003e\u003cli\u003eList of functions required to perform job duties\u003c/li\u003e\u003cli\u003eAuthorization and approval from applicable information account managers as described in the system security and privacy plan.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp; \u0026nbsp;4. The Primary Information System Security Officer (P-ISSO) (or alternate) is tasked with:\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsuring access control policies and procedures are followed.\u003c/li\u003e\u003cli\u003eAuditing account management activities to ensure compliance.\u003c/li\u003e\u003cli\u003eReviewing access privileges to ensure all users have justifiable permissions.\u003c/li\u003e\u003cli\u003eEnforce account management lifecycle activities.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe \u003cem\u003eCMS ARS\u003c/em\u003e requires removing or disabling default user accounts, renaming active default user accounts, implementing a centralized control of user access administrator functions, regulating and defining the access provided to contractors, searchable automated account management results by \u003ca href=\"https://security.cms.gov/learn/cms-cybersecurity-integration-center-ccic\"\u003eCMS Cybersecurity Integration Center (CCIC)\u003c/a\u003e, and all raw security information/results from relevant automated tools must be available in an unaltered format to the CCIC.\u003c/p\u003e\u003cp\u003eAccount managers must be notified when a CMS system user is terminated or transferred, and the user’s associated account removed, disabled, revoked, or otherwise secured within a Mission/Business/System-defined timeframe, and not to exceed 30 days from the date of termination or transfer. Account managers must also be notified when there are changes in the user's system usage or need to know.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated system account management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAutomated System Account Management is required to manage, create, enable, modify, disable, revoked, retire, and remove CMS system account(s) when a user is terminated or transferred. CMS access control tools leverage the use of emails or text messaging to notify managers and users of account lifecycle events. These tools have automated capabilities to review user account activities and usage and report atypical behavior using email notifications.\u003c/p\u003e\u003cp\u003eCMS system administrators must be notified via automated email whenever a user account lifecycle event has occurred. Automated email mechanisms must be in place to support the management of system accounts. Additionally, users are emailed prior to password expiration and are allowed to make the necessary password changes.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated temporary and emergency account management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAutomated temporary and emergency account management is required to automatically remove or disable the access rights of temporary or emergency accounts after a predefined period after activation rather than at the convenience of the system administrator. Automatic removal or disabling of accounts provides a more consistent implementation.\u003c/p\u003e\u003cp\u003eCMS temporary and emergency accounts are managed in accordance with the system’s account management procedures or the security and privacy plan. These accounts are provisioned only when necessary and authorized, and they must be established with a fixed duration based on the need not to exceed the CMS parameter.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable accounts\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to automatically disable accounts that are expired, no longer associated with a user or individual, violate CMS policy, or have been inactive for a predefined period.\u0026nbsp;\u003c/p\u003e\u003cp\u003eFor an inactive account, a scheduled task reconciles the Last Login Date from the system database and locks the user account if the period reached its expiration date. Users who have not logged in during the inactivity period are marked as inactive and their accounts locked. The user will be notified at the next logon attempt that their account has been locked and can make use of the self-unlock feature or an IT Service Desk request for a user account reset.\u003c/p\u003e\u003cp\u003eAll these processes support the concepts of least privilege and least functionality that reduce the attack surface of systems.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAutomated audit actions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS access control systems are required to utilize the capability to automatically produce event logs for system administrators to review for administrative actions. These may include account creation, modification, enabling, disabling, and removal actions for audit record review, analysis, and reporting. In addition to any other actions defined in the applicable system security and privacy plan.\u003c/p\u003e\u003cp\u003eCMS systems must be configured to log and audit the following account lifecycle events:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCreation\u003c/li\u003e\u003cli\u003eEnabling\u003c/li\u003e\u003cli\u003eModification\u003c/li\u003e\u003cli\u003eDisabling and;\u003c/li\u003e\u003cli\u003eRemoval (Retirement and Termination).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNotifications for these relevant and significant events are sent to the system administrators or managers as documented in the applicable security and privacy plan. Account actions in Active Directory (AD) are logged and exported to a Security Incident and Event Management (SIEM) tool where custom alerts are created, which notify appropriate individuals of these activities.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eInactivity logout\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eInactivity logout after a defined period reduces the risks of unauthorized access to CMS systems. This is accomplished by setting a lock on the system after 90 minutes of inactivity to prevent users from obtaining information from the display device while an authorized user is actively logged into the system or application. Users are also encouraged to lock their systems when leaving the vicinity and are required to log out at the end of a normal work period.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eUsage conditions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eClearly defined account usage conditions establish and describe the specific conditions or circumstances under which CMS system accounts can be used. These conditions help enforce the principle of least privilege, increase user accountability, and enable effective account monitoring. CMS defines these usage conditions for particular system accounts as necessary to provide adequate information protections and configure systems to enforce them.\u003c/p\u003e\u003cp\u003eThe following details the usage conditions that are set and must be met before access is granted to CMS systems:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS requires all users who have been provisioned a User ID to complete an initial and annual certification of access needs, as well as the security Computer Based Training (CBT) course. Access is revoked for users who have not complied with these requirements annually.\u003c/li\u003e\u003cli\u003eCMS users are required to accept the government warning displayed on the CMS warning banner before accessing CMS Government-Furnished Equipments (GFEs), CMS VPN connections, or CMS Virtual Desktop Infrastructure (VDI) using CITRIX Workspace connections. This warning banner is an acknowledgment of monitoring and usage restrictions.\u003c/li\u003e\u003cli\u003eAll users must complete all CMS system-related documentation including access request forms, \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eHHS rules of behavior\u003c/a\u003e for General Users, and any additional training required based on individuals with Significant Information Security Responsibilities (SISR), e.g., Role Based Training (RBT) for any user identified with significant information security and privacy responsibilities, as required in the applicable system security and privacy plan.\u003c/li\u003e\u003cli\u003eCMS users are prohibited from accessing systems from non-US locations during foreign travels without first obtaining official leadership approval. For more information on the approval process, review Chapter 10: Foreign Travel of the \u003cem\u003eCMS Physical Security Handbook\u003c/em\u003e.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAccount monitoring for atypical usage\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe administrative monitoring of activities associated with CMS system accounts is established to determine unusual and malicious use. CMS security teams monitor accounts for atypical usage that may include assessing systems at unusual days and times or from locations that are not consistent with the normal usage patterns of individuals, and for unusual information transfer volumes. Monitoring may also reveal rogue behavior by individuals or an attack in progress. There is coordination between CMS systems and the security teams through the CCIC to monitor system accounts and their usage and report to CMS incident response teams.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for monitoring user accounts for atypical usage.\u003c/p\u003e\u003cp\u003eCMS employs several security appliances and devices to assist with the ongoing monitoring of systems, as well as related system accounts, for atypical usage.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eFirewalls:\u003c/strong\u003e Network- and host-based firewalls are used to monitor traffic and generate daily reports covering the last 24 hours of activity.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity Information and Event Management (SIEM):\u003c/strong\u003e This solution is used to review logs generated from applications, databases, and servers for analysis by CMS security teams.\u003c/p\u003e\u003cp\u003eIn accordance with CMS information system Incident Response Plans, CMS CCIC should be notified immediately of potential security incidents upon discovery.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable accounts for high-risk individuals\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eDisabling the accounts for high-risk individuals reduces the risks posed by an insider threat that could adversely impact CMS IT assets, environment, operations, and individuals. Users who pose significant security or privacy risks include individuals for whom reliable evidence indicates either intention to use authorized access to a system to cause harm or through whom adversaries will cause harm.\u003c/p\u003e\u003cp\u003eDisabling accounts of high-risk individuals is a minimum requirement for the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior\u003c/a\u003e for Use of Information and IT Resources because of the possibility of abusing access privileges to sensitive information and CUI, including information protected under the Privacy Act.\u003c/p\u003e\u003cp\u003eAccount management activities must be expedited for the revocation of access for high-risk user accounts. Notification is sent to the appropriate security personnel as documented in the system security and privacy plan using the appropriate channels (email or phone). After being notified, the account must be disabled within a reasonable time frame not to exceed the CMS-established parameter from the time the high-risk account is identified.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccess enforcement\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAccess control policies and the associated access enforcement mechanisms are employed to automatically control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the systems. These access control mechanisms must restrict access to any sensitive information, CUI or personally identifiable information (PII) and protected health information (PHI).\u003c/p\u003e\u003cp\u003eCMS systems are configured to enforce approved authorizations for logical access to information and system resources that support its mission and business functions, in accordance with applicable access control policies.\u003c/p\u003e\u003cp\u003eFurther, access enforcement mechanisms can be employed at the application and service level to provide increased information security and privacy. Assigned privileges and rules are used to allow logical access to systems, applications, and databases. These privileges are assigned during the account creation and modification account lifecycle.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eControlled release\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eControlled release of information ensures systems implement technical or procedural means to validate the controls implemented by any external systems before releasing information to them. All external systems or entities (i.e., departments, agencies, or commercial entities not managed by CMS) must provide controls that are commensurate with those implemented by CMS to protect the released information. The means used to determine the adequacy of the controls provided by the recipient systems may include conducting periodic assessments (inspections/tests), establishing agreements between CMS and external entities, or some other process. The adequacy of the implemented controls on those external systems ensures a consistent adjudication of the security and privacy policy that protects the information and individuals’ privacy.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eIndividual access\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS allow access to individuals that enable them to review personally identifiable information about them collected via legislative mandates and healthcare programs. Access helps individuals to develop an understanding of how their personally identifiable information is processed, handled, and disseminated to ensure their data is accurate and secure. Access mechanisms can include request forms and application interfaces. As stipulated by the Privacy Act, individual record access procedures are contained in systems of record notices (SORN) and the SORNs published on the Federal Register and CMS/HHS websites.\u003c/p\u003e\u003cp\u003eHowever, individual access to certain types of records contained in the HHS Exempt Systems of Records may be exempt, in full or in part, from certain requirements of the Privacy Act, based on rulemakings promulgated under subsection (j) or (k) of the Privacy Act (5 U.S.C. § 552a(j), (k)). Note that 5 U.S.C §. 552a(d)(5) excludes material compiled in reasonable anticipation of a civil action or proceeding from the Privacy Act's access requirement, in all systems of records, without the need for rulemaking.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eInformation flow enforcement\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eInformation flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) without regard to subsequent access to that information. Flow control restrictions may include blocking external traffic that claims to be from within CMS, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from CMS's internal web proxy server, and limiting information transfers between CMS and other external entities based on data structures and content.\u003c/p\u003e\u003cp\u003eTransferring information between CMS and other external entities may require an agreement specifying how the information flow is enforced using \u003ca href=\"https://security.cms.gov/learn/cms-interconnection-security-agreement-isa\"\u003einterconnection security agreements (ISA)\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cms-information-exchange-agreement-iea\"\u003einformation exchange security agreements\u003c/a\u003e, \u003ca href=\"https://security.cms.gov/learn/cms-memorandum-understanding-mou\"\u003ememoranda of understanding or agreement (MOU/MOA)\u003c/a\u003e, service level agreements (SLA), or other exchange agreements (as defined in the applicable security and privacy plans).\u003c/p\u003e\u003cp\u003eInformation flow enforcement may also include prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regarding mechanisms to reassign security or privacy attributes and labels.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing information flow enforcement.\u003c/p\u003e\u003cp\u003eCMS uses a variety of methods and applications to enforce information flow with systems and between interconnected systems.\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CMS access control systems are configured to enforce approved authorizations within CMS information systems and other interconnections. For more information on interconnections and information sharing, please review AC-21 in the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e\u003cem\u003e.\u003c/em\u003e\u003c/li\u003e\u003cli\u003eVirtual Local Area Networks (VLANs) are used to provide environment and zone separation with firewall device control between each interconnected VLAN. Firewall rules are then configured to restrict information flows to only authorized users.\u003c/li\u003e\u003cli\u003eInterconnection between different server types within the CMS information system environment is controlled by network devices including firewalls. Rules are set up to allow traffic to authorized destination internet protocol (IP) addresses only.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eFlow control of encrypted information\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to prevent encrypted information from bypassing information flow control mechanisms by either blocking the flow of the encrypted information or terminating communications sessions that attempt to pass encrypted information. Flow control mechanisms may include content checking, security policy filters, and data type identifiers. The term encryption is extended to cover encoded data that are not recognized by the filtering mechanisms.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSeparation of duties\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSeparation of duties for CMS’s accounts is enforced to address the potential for abuse of authorized privileges and reduces the risk of malevolent activity without collusion. Each individual`s responsibilities and privileges within CMS`s environment are defined in a way that inhibits intentional or inadvertent unauthorized activity. Through the use of job codes, roles, and access rights, the workflows for authorization are separated in the CMS environment. A job code is a role that grants a group of users, access to defined resources. All ISSOs are required to ensure that these requirements are implemented effectively and meet the minimum control standards within the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e in their respective systems during authorization.\u003c/p\u003e\u003cp\u003eFurther, implementing separation of duties control reduces the risk of inappropriate access to CMS's sensitive information and CUI (e.g., separating employees that perform security and breach investigations from routine mission and business functions).\u003c/p\u003e\u003cp\u003eCMS Business owners control the access to their respective CMS systems. They create privileges that limit an individual's account access only to those systems for which there is a business need. Access rights are established while considering the separation of duties based on the following factors:\u003c/p\u003e\u003cul\u003e\u003cli\u003eDividing mission functions and information system support functions among different individuals and/or roles.\u003c/li\u003e\u003cli\u003eConducting information system support functions with different individuals (e.g., system management, programming, configuration management, quality assurance and testing, and network security).\u003c/li\u003e\u003cli\u003eEnsuring security personnel administering access control functions do not also administer approval or audit functions.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eLeast privilege\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS employs the principle of least privilege to ensure that its information system accounts are provisioned at privilege levels no higher than necessary to accomplish the mission/business functions. In other words, the system access privileges are only enough, i.e., at a minimum, for a user to perform their assigned duties as prescribed in their job descriptions. CMS systems are configured to prevent non-privileged accounts from having access to security or audit-related settings and controls. It is strictly prohibited to knowingly exceed authorized access according to the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eAt CMS, role-based access control is used to restrict access to system functions only to designated individuals. The restrictions must be based on the minimum necessary access required to complete specific system activities. These restrictions must be included in system-specific documentation, and are necessary to ensure that only authorized users are permitted access to files, directories, drives, workstations, servers, network shares, ports, protocols, and services that are expressly required for the performance of their job duties. Unnecessary access rights associated with services that are not required for the operation of the system should be disabled.\u003c/p\u003e\u003cp\u003eThe concept of least privilege aligns with the notion of limiting access to CMS's sensitive information and CUI to those individuals with a documented need to know in the performance of their job duties.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthorize access to security functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eSecurity functions in CMS are limited only to authorized personnel. Security functions include but are not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), configuring settings for events to be audited, and establishing intrusion detection parameters.\u003c/p\u003e\u003cp\u003eCMS personnel classified as privileged users, according to the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS \u003cem\u003eIS2P2\u003c/em\u003e\u003c/a\u003e, are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe following details the CMS-specific process for authorizing access to security functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAccess is granted based on the privileged role and approved job codes, with privileged functions restricted to individuals with administrative or security functionality requirements.\u003c/li\u003e\u003cli\u003eThe privileged account is restricted to privileged functions only and cannot be used to perform normal user (i.e., non-privileged accounts) functions concurrently.\u003c/li\u003e\u003cli\u003eApproved servers may use RBAC which is implemented using Active Directory (AD) group memberships. Non-privileged accounts have no access to servers.\u003c/li\u003e\u003cli\u003eSystem configurations and parameters are by group policy (GPO).\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eNon-privileged access for non-security functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe implementation of non-privileged access for nonsecurity functions limits security exposure or incidents that might occur when users perform operations from within privileged accounts or roles. CMS-privileged accounts or roles must be used only when necessary to perform system administration and security duties. Also, CMS systems must be configured to prevent non-privileged users from executing privileged functions.\u003c/p\u003e\u003cp\u003eCMS-privileged users with access to security functions are provisioned with and required to use their non-privileged accounts to perform duties that do not require that level of access. The separation of privileged and non-privileged accounts also prevents unintended or unauthorized loss, modification, or exposure. For example, a System Administrator (SYSADMIN) would have a separate account to perform SYSADMIN functions, and a typical USER account to perform normal user functions such as email, application access [Word Documents, Spreadsheets, Presentations, etc.], etc. The SYSADMIN cannot perform SYSADMIN functions under the typical USER account or role.\u003c/p\u003e\u003cp\u003eIn addition, the typical USER account or role cannot perform SYSADMIN-type functions such as administration/ management of the following: operating systems, network operations (telecommunications devices, firewalls, DMZ, servers, database administration, etc.), application servers, database servers, etc. In other words, any operation that would require Operating System (OS), ADMIN, or root-level access to perform ADMIN-type services or operations.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNetwork access to privileged commands\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS restricts the ability to perform privileged commands across the network connection as opposed to the local access on its systems. CMS limits network access to activities requiring elevated privileges to situations where there is a compelling operational need. For example, a compelling operational need may include routine administration (management) of remote security and infrastructure devices across a dedicated management network (see the \u003cem\u003eCMS Technical Reference Architecture [TRA]\u003c/em\u003e for additional information).\u003c/p\u003e\u003cp\u003eNetwork access to privileged commands is limited to specific roles listed as privileged users in \u003ca href=\"https://intranet.hhs.gov/policy/hhs-policy-information-security-and-privacy-protection-is2p\"\u003e\u003cem\u003eCMS IS2P2\u003c/em\u003e\u003c/a\u003e. These roles are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators\u0026nbsp;\u003c/li\u003e\u003cli\u003eAdditional roles as documented in the System Security and Privacy Plan (SSPP).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS personnel are approved for such access by requesting the necessary roles or privileges. The process of requesting and approving these roles or privileges (as documented in the system security and privacy plan) acts as a control to ensure the privilege is being assigned to the right user.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrivileged accounts\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS limits who is authorized to perform administrative or security functions on its systems. These functions may include configuring access permissions, setting audit logs, and performing system management functions. This level of access needs to be limited because it further protects sensitive information and CUI from being comprised by reducing the number of individuals who possess unnecessary high privileges.\u003c/p\u003e\u003cp\u003ePrivileged accounts are limited only to specific roles that require the performance of privileged functions in the CMS environment. These roles are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eApplication Administrators\u003c/li\u003e\u003cli\u003eDatabase Administrators\u003c/li\u003e\u003cli\u003eSystem Developers and Maintainers\u003c/li\u003e\u003cli\u003eSystem/Network Administrators\u003c/li\u003e\u003cli\u003eWebsite Owner/Administrators\u0026nbsp;\u003c/li\u003e\u003cli\u003eAdditional roles as documented in the SSPP.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS personnel are approved for such access through the appropriate account privileges. The process of requesting and approving these account privileges (as documented in the SSPP) acts as a control to ensure the privilege is being assigned to the right user.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eReview of user privileges\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIn CMS, certain assigned user privileges may change over time to reflect changes in the mission and business functions, environments of operation, technologies, or threats. A periodic review of all assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid. If the need cannot be revalidated, appropriate corrective actions must be taken to address it.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eLog use of privileged functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eLog the use of all privileged functions to ensure that there is accountability for all CMS system accounts with privileged functions because of the elevated permissions to access, and grant access, to sensitive information and CUI.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for logging the use of privileged functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS systems audit the use of privileged functions via logging user accounts that have the right to conduct privileged functions only on the system.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe audit logs must include a user account trail of privileged commands executed intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts.\u003c/li\u003e\u003cli\u003eThese logs are then audited and reviewed using a SIEM tool.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eProhibit non-privileged users from executing privileged functions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eProhibit non-privileged users from executing privileged functions so that appropriate individuals have access to privileged functions only based on their roles and responsibilities. Non-privileged users may not have the same level of trust as privileged users. Privileged users have access beyond that of a non-privileged user, and as such, may have a greater ability to access sensitive information and CUI. Privileged accounts typically may have root-level access to the system at the operating system (OS) level and therefore “keys to the kingdom” level of access to all components or services of that system. For this reason, systems must have the ability to trace (audit) the actions of the user who initiated them and what actions were taken.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe assignment of privileged functions to user accounts should be based on the role and the level of responsibility of the user, while still accounting for the principle of least privilege. Privileged functions are assigned to a user account through approved roles or privileges and the approval process acts as a safeguard to ensure access is being provisioned to the right user, who have been appropriately authorized for the escalated privilege.\u0026nbsp;\u003c/p\u003e\u003cp\u003eUsers' accounts are set up to allow only the necessary functions authorized, thereby enforcing the principle of least privilege.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eUnsuccessful logon attempts\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded counteracts denial of service attacks and ensures that the user account is accessed only by the owner of that account. Automatic account lockouts are initiated by systems and are usually temporary and automatically released after a predetermined period as established by the CMS system administrators.\u003c/p\u003e\u003cp\u003eThe implementation standards contained in the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e are determined by the system’s risk categorization as stated below:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHigh:\u003c/strong\u003e Configure the information system to lock out the user account automatically after three (3) invalid login attempts during a 120-minute time window. Require the lockout to persist until released by an administrator.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eModerate:\u003c/strong\u003e Configure the information system to lock out the user account automatically after five (5) invalid login attempts during a 120-minute time window. Require the lockout to persist for a minimum of one (1) hour.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eLow:\u003c/strong\u003e Configure the information system to disable access for at least fifteen (15) minutes after five (5) invalid login attempts during a 120-minute time window.\u003c/p\u003e\u003cp\u003eCMS users will experience a lockout if they reach the maximum number of invalid login attempts. Users will be locked out indefinitely and must contact the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/Request%2520IT%2520Service.aspx\"\u003eCMS IT Service Desk\u003c/a\u003e or their system administrator to request their account to be unlocked.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSystem use notification\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS systems are configured to display an approved notification to be accepted by users before login. This notification provides appropriate security and privacy notifications as well as terms of use of the system. All CMS information systems are configured to display a system-use notification message before granting access. This is commonly referred to as a “System Warning Banner”.\u0026nbsp;\u003c/p\u003e\u003cp\u003eHHS has an established language approved for use as defined in the \u003cem\u003eCMS ARS AC-08 System Use Notification \u003c/em\u003econtrol. The system must use the HHS-approved warning banner text unless the system is collecting Federal Tax Information (FTI), then the \u003ca href=\"https://www.irs.gov/pub/irs-pdf/p1075.pdf\"\u003eIRS Publication 1075\u003c/a\u003e requires the system to use the approved text specified in Exhibit 8 Warning Banner Examples from the \u003cem\u003eIRS AC-08 System Use Notification\u003c/em\u003e control standard. The warning banner notification message must be displayed upon successful logon, obtaining an affirmation in the workflow from the user of their understanding and acceptance of the warning before gaining system access. This warning message notifies users that the CMS system is owned by the U.S. Government and describes conditions for access, acceptable use, and access limitations. The warning is presented at the secure gateway, and again at the system/device level. The approved warning/notification message should require forced user interaction and require the user to explicitly select the “I Accept” button before proceeding to log on to the system. The system should retain the notification message or banner on the screen until users take the explicit action(s) to log on to or further access the system.\u003c/p\u003e\u003cp\u003eThe warning banner language has very important legal implications for CMS and its system resources. Should content need to be added to this banner, submit the modified warning banner language to the CMS CIO for review and approval prior to implementation. If a system has character limitations related to the warning banner display, the CMS CIO can provide an abbreviated warning banner version. The \u003ca href=\"https://www.irs.gov/pub/irs-pdf/p1075.pdf\"\u003eIRS Publication 1075\u003c/a\u003e in Exhibit 8 Warning Banner Examples also has approved abbreviated warning banner versions available to use. If this banner is inconsistent with any directives, policies, regulations, or standards, notify the CMS CIO immediately.\u003c/p\u003e\u003cp\u003eAll systems and network devices under CMS control must prominently display the notice and consent banner immediately upon users’ authentication to the system, including, but not limited to, websites, web pages where substantial personal information from the public is collected, Secure File Transfer Protocol (SFTP), Secure Shell (SSH), or other services accessed.\u003c/p\u003e\u003cp\u003eThe \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003e\u003cem\u003eCMS ARS\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003eprovides additional requirements for the content and the implementation of System Use Notifications as specified by the AC-08 System Use Notification control standard.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eConcurrent session control\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS defines and implements the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or any combination thereof. A session is defined as an encounter between an end-user interface device (e.g., computer, terminal, process) and an application, including a network logon. One user session is the time between starting the application and quitting or exiting the application. For example, if a user can use separate browsers to open concurrent sessions with the same user account and log out of any of the concurrent sessions to terminate the other sessions, safeguards must be implemented to counteract this type of action.\u003c/p\u003e\u003cp\u003eCMS limits network log-on sessions to one (1) user/network/application session at a time by implementing the appropriate configuration settings. However, if a concurrent session of more than one (1) is required for the system, it needs to be documented in the applicable SSPP and approved by the CMS Authorizing Official (AO) during the Authorized To Operate (ATO) approval process.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDevice lock\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eDevice locks are actions taken to prevent logical access to systems when a period of inactivity has been detected on a CMS user account. This control is configured to protect sensitive information and CUI from unauthorized access when CMS system users are away from their workstations for a CMS-defined period of inactivity. Identification and authentication requirements must be met for users to re-establish access to the system. Group Policy is used to configure the device lock requirements.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing device lock:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS information systems, along with GFE computers distributed to CMS Federal staff and contractors, are configured with a fifteen (15) minute device lock on the operating system. The user will be required to re-authenticate themselves to continue accessing CMS resources.\u003c/li\u003e\u003cli\u003eWindows and UNIX servers are configured to lock the application, after thirty (30) minutes of inactivity. The user will be required to re-authenticate themselves to continue accessing CMS resources.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePattern-hiding displays\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePattern-hiding displays conceal, via the device lock, information with a publicly viewable image. All CMS systems are configured to conceal information that is previously available on the display with a screen saver. Pattern-Hiding Displays mitigate against unauthorized viewing of any sensitive information and CUI, especially PII or PHI. This type of threat is commonly referred to as “shoulder surfing”.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing pattern-hiding displays:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe system conceals information previously available on the display with a screen saver built into the operating system of the GFE.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS users can make use of this display before leaving GFE computers unattended or concealing information from unauthorized personnel.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe login screen is only available by pressing CTRL-ALT-DEL.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eSession termination\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSession termination ensures that all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) continue after the session is terminated. The conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.\u003c/p\u003e\u003cp\u003eCMS systems are configured to terminate user login sessions after a certain period of inactivity. For systems-specific login sessions, the system must implement automatic session termination based on a predefined condition or trigger outlined in their respective system security and privacy plan (SSPP).\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePermitted actions without identification or authentication\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSome specific user actions are permitted on CMS systems without identification or authentication required. Systems may allow a limited number of user actions like access to CMS public websites or other publicly accessible CMS systems that do not contain any sensitive information and CUI, but only the information that is appropriate for public consumption.\u003c/p\u003e\u003cp\u003eAll CMS systems that are not intended to be utilized by the public require proper user account processes and authentication. Please refer to the \u003ca href=\"https://pages.nist.gov/800-63-4/\"\u003eNIST Special Publication (SP) 800-63\u003c/a\u003e series regarding Digital Identity Guidelines (NIST SP 800-63, SP 800-63A, SP 800-63B, SP 800-63C).\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRemote access\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eRemote access is access to CMS systems by users (or processes acting on behalf of users) that communicate through external networks (for example, the Internet or non-secure telecommunication pathways and protocols) via CMS-approved VPNs or CMS VDI via the CITRIX Workspace. The use of CMS-approved VPNs or VDI does not make the access non-remote. However, the use of VPNs or VDI, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) provides sufficient information security assurance to the organization that it can effectively treat such connections as safe internal networks. Remote access to CMS network resources is securely configured and must meet, as a minimum, the following security requirements for posture validation:\u003c/p\u003e\u003col\u003e\u003cli\u003eUp-to-date system patches\u003c/li\u003e\u003cli\u003eCurrent malware/anti-virus software with up-to-date patches\u003c/li\u003e\u003cli\u003eA host-based intrusion detection system(s)\u003c/li\u003e\u003cli\u003eDisable functionality that provides the capability for automatic execution of code and\u003c/li\u003e\u003cli\u003eEmploys CMS-required encryption which is the Federal Information Processing Standard (FIPS) 140-2 validated cryptographic module at a minimum.\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eThe following details the CMS-specific process for implementing the remote access control:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe system should utilize a CMS-approved VPN(s) or VDI to ensure the security of the sessions and the integrity of client-based applications.\u003c/li\u003e\u003cli\u003eCMS users are not allowed to access CMS systems remotely without a CMS-issued RSA hard token or \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-3.pdf\"\u003eFIPS 201\u003c/a\u003e PIV card, along with an approved EUA job code.\u003c/li\u003e\u003cli\u003eAccess to the secure CMS VPN or CMS VDI will authenticate the user account using the EUA job code.\u003c/li\u003e\u003cli\u003eThe VPN solution used by CMS also includes a Network Access Control (NAC) component that performs a security assessment and verifies the latest critical operating system patches and up-to-date malware/anti-virus signatures.\u0026nbsp;\u003c/li\u003e\u003cli\u003eIf the computer fails any one of these checks, it will be quarantined, i.e., preventing remote users from connecting to the CMS network with machines that aren't up to date with malware/anti-virus signatures or OS patch levels, and securing the computer by placing VPN login credentials into a secured area with limited or no access to the CMS network until those conditions are remediated. In the remediation process, CMS users are instructed to obtain required updates from Windows Software Update Service (WSUS) servers or other update servers.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS contractors will be notified that they will need to disconnect from the VPN and update their computers by downloading the latest Microsoft critical patches and/or antivirus signatures before access is granted.\u003c/li\u003e\u003cli\u003eRemote access for privileged functions must be permitted only for compelling operational needs, must be strictly controlled, and must be explicitly authorized, in writing, by the CMS AO, i.e., the CIO (Chief Information Officer) or his/her designated representative.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAdditional information on connecting to the CMS Network using an approved CMS VPN service can be found in the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/RemoteAccessSupport.aspx?PageView=Shared\u0026amp;InitialTabId=Ribbon.WebPartPage\u0026amp;VisibilityContext=WSSWebPartPage#Remote\"\u003eRemote Access Support\u003c/a\u003e. Additional information for CMS Federal Employees or contractors using the CMS VDI can be found at \u003ca href=\"https://vdildap.cms.gov/logon/CMS_VDI_HOW_TO_GUIDE.pdf\"\u003eCMS Employees and Contractors How-To-Guide VDI\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMonitoring and control\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS systems are configured to employ automated mechanisms and establish parameters that facilitate the monitoring and control of remote access. User activities are also monitored and audited to ensure compliance with CMS remote access policies, as applicable to each CMS information system. For more information on remote access, visit the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/RemoteAccessSupport.aspx?PageView=Shared\u0026amp;InitialTabId=Ribbon.WebPartPage\u0026amp;VisibilityContext=WSSWebPartPage#Remote\"\u003eCMS Remote Access Support\u003c/a\u003e website.\u003c/p\u003e\u003cp\u003eAn Intrusion Detection System (IDS) is deployed to protect and monitor the integrity of the systems. Continuous monitoring is also deployed by the CMS Information Security and Privacy Group (ISPG) to ensure compliance with CMS policies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eProtection of confidentiality and integrity using encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems shall implement cryptographic mechanisms to protect remote access sessions. All encryption solutions used throughout CMS must be \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf\"\u003eFIPS 140-3\u003c/a\u003e tested and validated. The confidentiality and integrity of remote sessions, sensitive information and CUI shall be protected with end-to-end encryption commensurate with the sensitivity level of the data.\u003c/p\u003e\u003cp\u003eSystems must utilize a CMS-approved secure VPN or VDI solution to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Every access to the CMS Secure VPN or VDI requires authentication using secure user system account credentials.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWhen applicable and available, sessions should be secured with FIPS 140-3 hardware security modules and FIPS 140-3 compliant algorithms.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManaged Access Control points\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS remote accesses must be routed through authorized and managed network access control points to protect the network connections. A Trusted Internet Connection (TIC) must be utilized for all external network connections.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing managed access control points:\u003c/p\u003e\u003cp\u003eAll systems must utilize CMS-approved secure VPN or VDI connections to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Administrative access should be limited to designated CMS-approved VPN or VDI solutions. Based on the designated VPN or VDI solution, configurations for firewall rules, Intrusion Detection and Prevention System policies, server policies, and active directory group policies as implemented in collaboration with AC control family requirements, will limit remote access.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrivileged commands and access\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe execution of privileged commands and access via remote access is restricted. Remote access for privileged commands and access should only be permitted if operational needs cannot otherwise be met via a direct connection in a secured access-controlled environment.\u003c/p\u003e\u003cp\u003eSystems should be configured to allow privileged user accounts to execute privileged commands to security-relevant information via remote access under special circumstances associated with the need to complete a task for critical operational needs. If a system opts to enable appropriate privileged commands via remote access, the rationale for the permission must be documented in the SSPP and approved via the CMS AO during the ATO approval process.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWireless access\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS monitors for unauthorized wireless access and prohibits the installation of wireless access points (WAP) in its systems. The Infrastructure and User Services Group (IUSG) are in charge of managing wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS information systems and prohibits the installation of WAP to systems unless explicitly authorized, in writing, by the CMS AO, i.e., the CMS CIO or the designated representative.\u003c/p\u003e\u003cp\u003eIf wireless access is authorized and approved by the AO during the ATO process, CMS establishes usage restrictions and configuration/connection requirements such as:\u003c/p\u003e\u003cul\u003e\u003cli\u003eFIPS 140-3 encryption protection is enabled\u003c/li\u003e\u003cli\u003eAccess points are placed in secure areas where physical access controls can be implemented, monitored, and audited\u003c/li\u003e\u003cli\u003eAccess points are shut down, i.e., powered off, when not in use (nights, weekends)\u003c/li\u003e\u003cli\u003eA stateful inspection firewall is implemented between the wireless network and the wired infrastructure; where a direct telecommunication wired connection is established\u003c/li\u003e\u003cli\u003eMedia Address Control (MAC) address authentication is utilized\u003c/li\u003e\u003cli\u003ePersonal firewalls are utilized on the endpoint device, e.g., laptop, and file sharing is disabled on all wireless clients\u003c/li\u003e\u003cli\u003eIntrusion detection agents are deployed on the wireless side of the firewall device\u003c/li\u003e\u003cli\u003eWireless activity is monitored and recorded, and the records are regularly reviewed\u003c/li\u003e\u003cli\u003eAdheres to \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Wireless-Acceptable-Use-Policy.pdf#search=cms%2520rules%2520of%2520behavior\"\u003eCMS Policy for Wireless Client Access\u003c/a\u003e and \u003ca href=\"https://www.hhs.gov/sites/default/files/standard_2009-0003_001s_-_ocio.DOC\"\u003eHHS Standard for IEEE 802.11 Wireless Local Area Network (WLAN)\u003c/a\u003e.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eRogue wireless devices, i.e., unauthorized WAPs, that are connected to the network can be detected by the wireless intrusion prevention system (WIPS). Any unauthorized WAP connected to the CMS internal network will be detected and locked out at the switch level (performing a port lock action on the switch IP address connection point) and then followed up as a potential security incident using the CMS Incident Response Process. For additional information on how to connect an approved wireless connection to CMS, please refer to the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Wireless-Network-Employee-Connection-Guide.pdf\"\u003eCMS Wireless Network Connection Guide\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthentication and encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems are protected against wireless networking capabilities by using authentication and the encryption of both users and devices. Wireless networking capabilities represent a significant potential vulnerability that can be exploited by adversaries.\u003c/p\u003e\u003cp\u003eThe CMS Baltimore Data Center Group (BDCG) manages the wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS systems and prohibits the installation of WAP devices to systems unless explicitly authorized, in writing, by the CMS AO, i.e., the CMS CIO or the designated representative. For more information on Authentication and Encryption, please refer to the System and Communications Protection (SC) and the Identification and Authentication (IA) Controls of the \u003cem\u003eCMS ARS\u003c/em\u003e.\u003c/p\u003e\u003cp\u003eAll wireless access points are configured to authenticate users and devices before access is granted. Also, all WLAN components use FIPS 140-3 approved cryptographic algorithms to protect the confidentiality and integrity of WLAN communications.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDisable wireless networking\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll wireless network capabilities embedded within CMS systems components must be disabled before issuance and deployment. Disabling all the wireless capabilities when not needed for essential CMS missions or functions can reduce susceptibility to threats by adversaries involving wireless technologies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRestrict configurations by users\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccess enforcement mechanisms are employed to restrict access to configure wireless networking capability only to selected and authorized users. Only CMS-approved and authorized users should be allowed to configure network capabilities. The responsibility of securing the CMS wireless network should rest in the hands of network administrators with system administrator (SYSADMIN) type accounts, that only allow SYSADMIN type commands to be performed under this type of SYSADMIN role.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing restrictions on access to wireless configurations.\u003c/p\u003e\u003col\u003e\u003cli\u003eCMS restricts access to wireless networking configurations only to the authorized role of a network administrator.\u003c/li\u003e\u003cli\u003eWireless networking capabilities are also confined within CMS boundaries.\u003c/li\u003e\u003c/ol\u003e\u003ch2\u003e\u003cstrong\u003eAntennas and transmission power levels\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS limits the unauthorized use of wireless communications outside of CMS-controlled boundaries. Radio antennas and transmission power levels must be calibrated to reduce the probability that usable signals can be intercepted by unauthorized users. Network traffic must be continuously monitored within CMS boundaries to detect and respond to intrusion and network misuse.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAccess Control for mobile devices\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAll CMS-controlled mobile devices, including when such devices are outside of the CMS-controlled areas, must abide by the established configuration requirements, connection requirements, and implementation guidance in the CMS ARS when connected to the CMS environment.\u003c/p\u003e\u003cp\u003eCMS network administrators must set usage restrictions, configuration, and connection requirements for all mobile devices. The \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Documents/CMS-Mobile-Device-Guidance.pdf#search=CMS%2520Guidance%2520for%2520Government%2520Furnished%2520Mobile%2520Devices\"\u003eCMS Guidance for Government Furnished Mobile Devices\u003c/a\u003e provides information on the responsible use of CMS-issued mobile devices.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for implementing access control requirements for mobile devices:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAll CMS-issued laptops utilize full disk encryption software that is FIPS 140-3 validated\u003c/li\u003e\u003cli\u003eCMS-procured removable storage media are configured for use by the contracted maintainer and use CMS-approved encryption for the storage of information\u003c/li\u003e\u003cli\u003eAny non-GFE equipment being connected internally to the network requires a fully signed \u003ca href=\"https://www.hhs.gov/sites/default/files/rules-of-behavior.pdf\"\u003eRules of Behavior for General Users\u003c/a\u003e form which details CMS' Operational Division (OpDiv) security responsibilities relative to the equipment being connected, along with prior approval from the CMS AO during the ATO process. The document also details the responsibilities the requester will fulfill or face possible disciplinary and/or non-disciplinary actions. Please refer to the HHS RoB, Section 6.3 Non-compliance for a list of potential adverse actions that may be taken against a user for non-compliance.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eGFE equipment may be connected remotely via VPN (using the established VPN for the Contractors' process). VPN authentication involves remote NAC checks that ensure the integrity of the system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFull device or container-based encryption\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS-issued mobile devices must be encrypted using full device or container-based encryption mechanisms to protect the confidentiality and integrity of the data and information contained. Container-based encryption provides a more fine-grained approach to data and information encryption on mobile devices, including encrypting selected data structures such as files, records, or fields. Since mobile devices are more likely to be lost or stolen, sensitive information on a mobile device(s) is more vulnerable to unauthorized disclosures and encryption reduces this vulnerability.\u003c/p\u003e\u003cp\u003eAt CMS, FIPS 140-3 encryption mechanisms are used to protect the confidentiality and integrity of information on CMS-issued mobile devices. CMS utilizes media and port protection software to encrypt removable media endpoint devices.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eUse of external systems\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS employs mechanisms that prohibit the use of external devices to access the systems within the network without a formal approval process. CMS complies with the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e, which strictly prohibits the use of personal devices to conduct CMS-related business without written and approved authorization by the CMS AO under the ATO approval process.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for the use of external information systems control requirements:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS prohibits the use of external systems without explicit written approval from the AO.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS does not allow the use of external systems that are not approved and do not meet CMS security requirements. If approval is granted, the recipient verifies the terms and conditions, ensures the required controls are implemented for the identified FIPS 199 system categorization to mitigate the associated risks, limits user access accordingly, and documents the control implementations in the SSPP.\u003c/li\u003e\u003cli\u003eAccess to PII from external systems (including, but not limited to, personally owned information systems/devices) is reinforced by a binding agreement to terms and conditions of the CMS’s privacy requirements to ensure awareness and accountability of both parties under the Interconnection Security Agreement approval process.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eLimits on authorized use\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS ensures that only authorized users are permitted to use external systems to access its systems, and these systems must have the necessary security configurations implemented before access is granted. These necessary security requirements are implemented and the CMS access control policies regarding the use of external systems are enforced.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for limiting the authorized use of external information systems:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS does not permit the use of external systems that are not approved and do not meet the CMS security requirements for accessing CMS systems per the \u003ca href=\"https://security.cms.gov/policy-guidance/hhs-policy-rules-behavior-use-information-it-resources\"\u003eHHS Policy for Rules of Behavior For Use of Information and IT Resources\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eExternal systems can only access CMS systems using approved VPN or VDI access and firewall/security verification software, which must be installed on each machine. This applies to federal employees and contractor personnel utilizing CMS GFE (laptop or desktop) only or approved corporate-issued computers per the contract.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePortable storage devices — restricted use\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS limits the use of its controlled-portable storage devices in external systems. Conditions of use or restrictions on these devices should be documented and configured by network administrators.\u003c/p\u003e\u003cp\u003eCMS has configured CMS-issued portable and mobile devices to meet federal requirements. CMS has provided several control implementations that support and manage how its information is used within portable storage devices. These include a policy to incorporate a methodology for protecting the information and the rules used to manage the information while in transit. For more information, review the \u003ca href=\"https://cmsintranet.share.cms.gov/CT/Pages/StorageDeviceandEncryption.aspx\"\u003eCMS Storage Device and Encryption\u003c/a\u003e website.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eInformation sharing\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eInformation sharing control puts restrictions on CMS-sensitive information and CUI, such as personally identifiable information (PII), contract-sensitive information, proprietary information, and classified information related to special access programs or compartments, based on a formal or administrative risk-based determination. Depending on the information-sharing circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program/compartment.\u003c/p\u003e\u003cp\u003eGuidance for information sharing between CMS and other organizations is specified in the CMS Privacy Handbook. The document specifies the requirements for information sharing in the following documents:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-interconnection-security-agreement-isa\"\u003eInterconnection Security Agreement (ISA):\u003c/a\u003e System interconnections are defined within CFACTS and require a supporting “signed” ISA between CMS and non-CMS organizations as part of the SSP/ATO process.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-memorandum-understanding-mou\"\u003eMemorandum of Understanding (MOU):\u003c/a\u003e Defines the relationship of two or more federal partners that enter into a joint project or collaboration in which they each contribute their resources.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-data-use-agreement-dua\"\u003eData Use Agreement (DUA):\u003c/a\u003e 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.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-information-exchange-agreement-iea\"\u003eInformation Exchange Agreements (IEA):\u003c/a\u003e Is needed when Personally Identifiable Information (PII) needs to be shared externally, and that will not have an adverse impact on the beneficiary.\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cms-computer-matching-agreement-cma\"\u003eComputer Matching Agreements (CMA):\u003c/a\u003e A written agreement establishing the conditions, safeguards, and procedures under which a federal agency agrees to disclose data with another federal or state agency when there is a computerized comparison of two or more automated Systems of Records (SORs).\u003c/li\u003e\u003cli\u003eOther forms of documented agreements required for different situations.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor additional guidance related to the above agreements and documents, please review the Privacy Handbook. The ISSO is responsible for developing and managing any agreement utilized for information sharing and should coordinate with the appropriate Data Guardian and Privacy Advisor.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePublicly accessible content\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePer applicable laws, executive orders, directives, policies, regulations, standards, and guidelines, the general public is not authorized to access non-public information, such as information protected under the Privacy Act information (e.g., PII/PHI), CMS sensitive information (e.g., data with a federal information classification standard, For Official Use Only [FOUO], or Controlled Unclassified Information [CUI]), and CMS proprietary information (e.g., proprietary acquisition data). This control addresses systems that are controlled by CMS and are accessible to the public, typically without requiring identification or authentication.\u003c/p\u003e\u003cp\u003eThe following details the CMS-specific process for adhering to requirements for publicly accessible content:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNetwork Connections\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eCMS Website Owners/Administrators are charged with limiting the connections to publicly available CMS websites and web services to approved secure protocols and adhering to Hypertext Transfer Protocol (HTTP) Strict Transport Security (HSTS) practices.\u003c/p\u003e\u003cul\u003e\u003cli\u003eAlthough general public access to the CMS internal network is not allowed, CMS websites are accessible by the public and protected by several Private Internet Exchange (PIX) firewalls\u003c/li\u003e\u003cli\u003eOutbound internet connections from CMS users are protected by Application Intelligence (NG AI) firewalls.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003ePublic Content\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CMS system personnel should reach out to the CMS Information Security and Privacy Group (ISPG) to review the proposed content of information on a publicly accessible system (including a public website) before posting or publication to ensure that nonpublic information is not included.\u003c/li\u003e\u003cli\u003eThe frequency of the review will be commensurate with the frequency information is posted. Whenever new information is being considered to be uploaded to a site, it should trigger a review process to ascertain it complies with CMS policy.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe system should consult the ISPG for clarification as to if the information is suitable for public accessibility and publication.\u003c/p\u003e"])</script><script>self.__next_f.push([1,"194:{\"value\":\"$195\",\"format\":\"body_text\",\"processed\":\"$196\",\"summary\":\"\"}\n199:[]\n198:{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security \u0026 Privacy Policy (IS2P2) \",\"options\":\"$199\",\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"}\n19b:[]\n19a:{\"uri\":\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\",\"title\":\"NIST Security and Privacy Controls for Information Systems and Organizations\",\"options\":\"$19b\",\"url\":\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"}\n19d:[]\n19c:{\"uri\":\"entity:node/1112\",\"title\":\"Security Operations\",\"options\":\"$19d\",\"url\":\"/ispg/security-operations\"}\n197:[\"$198\",\"$19a\",\"$19c\"]\n19e:{\"value\":\"A guide that provides an overview of the policies, procedures, and processes needed to implement security requirements for the Access Control (AC) family\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eA guide that provides an overview of the policies, procedures, and processes needed to implement security requirements for the Access Control (AC) family\u003c/p\u003e\\n\"}\n192:{\"drupal_internal__nid\":1126,\"drupal_internal__vid\":6181,\"langcode\":\"en\",\"revision_timestamp\":\"2025-01-22T14:43:00+00:00\",\"status\":true,\"title\":\"CMS Access Control Handbook\",\"created\":\"2023-06-29T13:37:08+00:00\",\"changed\":\"2025-01-22T14:43:00+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":\"$193\",\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":\"$194\",\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_last_reviewed\":\"2023-06-20\",\"field_related_resources\":\"$197\",\"field_short_description\":\"$19e\"}\n1a2:{\"drupal_internal__target_id\":\"library\"}\n1a1:{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":\"$1a2\"}\n1a4:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/node_type?resourceVersion=id%3A6181"])</script><script>self.__next_f.push([1,"\"}\n1a5:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/node_type?resourceVersion=id%3A6181\"}\n1a3:{\"related\":\"$1a4\",\"self\":\"$1a5\"}\n1a0:{\"data\":\"$1a1\",\"links\":\"$1a3\"}\n1a8:{\"drupal_internal__target_id\":6}\n1a7:{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":\"$1a8\"}\n1aa:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/revision_uid?resourceVersion=id%3A6181\"}\n1ab:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/revision_uid?resourceVersion=id%3A6181\"}\n1a9:{\"related\":\"$1aa\",\"self\":\"$1ab\"}\n1a6:{\"data\":\"$1a7\",\"links\":\"$1a9\"}\n1ae:{\"drupal_internal__target_id\":26}\n1ad:{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":\"$1ae\"}\n1b0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/uid?resourceVersion=id%3A6181\"}\n1b1:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/uid?resourceVersion=id%3A6181\"}\n1af:{\"related\":\"$1b0\",\"self\":\"$1b1\"}\n1ac:{\"data\":\"$1ad\",\"links\":\"$1af\"}\n1b4:{\"drupal_internal__target_id\":91}\n1b3:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":\"$1b4\"}\n1b6:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/field_resource_type?resourceVersion=id%3A6181\"}\n1b7:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/field_resource_type?resourceVersion=id%3A6181\"}\n1b5:{\"related\":\"$1b6\",\"self\":\"$1b7\"}\n1b2:{\"data\":\"$1b3\",\"links\":\"$1b5\"}\n1bb:{\"drupal_internal__target_id\":66}\n1ba:{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":\"$1bb\"}\n1bd:{\"drupal_internal__target_id\":81}\n1bc:{\"type\":\"taxonomy_term--roles\",\"id\":\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\",\"meta\":\"$1bd\"}\n1bf:{\"drupal_internal__target_id\":61}\n1be:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-47"])</script><script>self.__next_f.push([1,"4f-8536-ad7db1b2e5ab\",\"meta\":\"$1bf\"}\n1c1:{\"drupal_internal__target_id\":76}\n1c0:{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":\"$1c1\"}\n1c3:{\"drupal_internal__target_id\":71}\n1c2:{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"meta\":\"$1c3\"}\n1b9:[\"$1ba\",\"$1bc\",\"$1be\",\"$1c0\",\"$1c2\"]\n1c5:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/field_roles?resourceVersion=id%3A6181\"}\n1c6:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/field_roles?resourceVersion=id%3A6181\"}\n1c4:{\"related\":\"$1c5\",\"self\":\"$1c6\"}\n1b8:{\"data\":\"$1b9\",\"links\":\"$1c4\"}\n1ca:{\"drupal_internal__target_id\":16}\n1c9:{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":\"$1ca\"}\n1c8:[\"$1c9\"]\n1cc:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/field_topics?resourceVersion=id%3A6181\"}\n1cd:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/field_topics?resourceVersion=id%3A6181\"}\n1cb:{\"related\":\"$1cc\",\"self\":\"$1cd\"}\n1c7:{\"data\":\"$1c8\",\"links\":\"$1cb\"}\n19f:{\"node_type\":\"$1a0\",\"revision_uid\":\"$1a6\",\"uid\":\"$1ac\",\"field_resource_type\":\"$1b2\",\"field_roles\":\"$1b8\",\"field_topics\":\"$1c7\"}\n18f:{\"type\":\"node--library\",\"id\":\"4c71fa83-e15c-4187-a479-696657ea5e15\",\"links\":\"$190\",\"attributes\":\"$192\",\"relationships\":\"$19f\"}\n1d0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06?resourceVersion=id%3A5561\"}\n1cf:{\"self\":\"$1d0\"}\n1d2:{\"alias\":\"/policy-guidance/cms-privacy-impact-assessment-pia-handbook\",\"pid\":411,\"langcode\":\"en\"}\n1d4:T5673,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is the purpose of a Privacy Impact Assessment (PIA)?\u0026nbsp;\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Privacy Impact Assessment (PIA) is an analysis of how personally identifiable information (PII) is collected, used, shared, and maintained. The purpose of a PIA is to demonstrate that system owners have consciously incorporated privacy protections within their systems for information supplied for by the public.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePIAs are required by the E-Government Act of 2002, which was enacted by Congress in order to improve the management of Federal electronic government services and processes. Section 208 of the E-Government Act specifically requires PIAs to be created when a federal agency develops or procures new information technology that involves the collection, maintenance, or dissemination of information in identifiable form.\u003c/p\u003e\u003cp\u003eFurther, because the E-Government Act also includes a provision requiring PIAs to be published publicly on agency websites, they allow CMS to communicate more clearly with the public about how we handle information, including how we address privacy concerns and safeguard information. Copies of completed PIAs are\u003ca href=\"https://www.hhs.gov/pia/index.html\"\u003e posted on the HHS website\u003c/a\u003e upon completion to offer transparency to the public.\u003c/p\u003e\u003cp\u003ePIAs must be completed in the following situations:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eFor all new systems that collect PII from 10 or more members of the general public, a PIA is required to be completed as part of the broader Authority to Operate (ATO) process.\u003c/li\u003e\u003cli\u003eFor every existing system that collects PII from 10 or more members of the general public, a PIA must be reviewed and re-approved once every three years. System/Business Owners and Information System Security Officers (ISSOs) must review and revise as necessary, and submit PIAs for re-approval no later than three years from the last HHS approval date.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor any existing system undergoing a \u003cstrong\u003emajor change\u003c/strong\u003e, an updated PIA is required.\u003c/li\u003e\u003cli\u003eAn existing system that is going through the ATO process may need to update their PIA paperwork if it’s close to expiring; an ATO cannot be completed with an expired or incomplete PIA.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIf your FISMA system does not meet the requirements above, it may not require a traditional PIA. In these instances, there may be other Privacy compliance requirements for your system or application. For example, you may be required to complete a different type of assessment (such as a Privacy Threshold Analysis (PTA), Third Party Website Application (TPWA) Privacy Impact Assessment, or Internal Privacy Impact Assessment).\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePIA roles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003ch3\u003e\u003cstrong\u003eHHS Chief Information Officer (CIO)/Senior Agency Official for Privacy (SAOP)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAt HHS, the Chief Information Officer (CIO) is designated as the Senior Agency Official for Privacy (SAOP) and provides the overall program structure for the completion of PIAs across all operating divisions. Responsibilities for the SAOP include, but are not limited to the following:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDevelop a standard form for HHS PIAs\u003c/li\u003e\u003cli\u003eReview PIAs from all operating divisions for adequacy, consistency, and compliance with federal and HHS requirements\u003c/li\u003e\u003cli\u003eIf the PIA meets HHS’s requirements, the PIA is signed by the SAOP, which finalizes the PIA for a period depending on the type of PIA\u003c/li\u003e\u003cli\u003eEnsure all PIAs are published and made publicly available on HHS.gov\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Senior Official for Privacy (SOP)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAt CMS, the Senior Official for Privacy (SOP) is the lead privacy official responsible for administering the agency PIA process and providing direction for the CMS privacy program. Unresolved privacy risks and other potential issues should be addressed before submission to the CMS SOP for final review. Responsibilities of the CMS SOP include, but are not limited to the following:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eEstablish a CMS specific framework for the development and completion of PIAs in accordance with federal and HHS requirements\u003c/li\u003e\u003cli\u003eReview and approve all PIAs for completion and consistency prior to submission to the HHS SAOP in coordination with the CMS Final Approver\u003c/li\u003e\u003cli\u003eSigning the PIA on behalf of CMS once the PIA satisfies federal and HHS requirements (The PIA will still require HHS’s final signature before publication to the HHS website)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS System Owner/Business Owner\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eInformation System Owners or Business Owners are individuals who are responsible for CMS FISMA systems or electronic information collections. System/Business Owners:\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview, revise, and submit PIAs for approval for new systems or re-approval whenever a change to an IT system, a change in CMS practice, or another factor alters the privacy risks associated with the use of the IT system or electronic information collection.\u0026nbsp;\u003c/li\u003e\u003cli\u003eAllocate proper resources to permit identification and remediation of privacy risks and weaknesses identified on PIAs.\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview, revise, and submit PIAs for re-approval three years from the last approval date, and as part of the authorization process as required.\u0026nbsp;\u003c/li\u003e\u003cli\u003eComply with all relevant Privacy Act requirements regarding any system of records, including, but not limited to, providing individuals with procedures for access and amendment of records.\u003c/li\u003e\u003cli\u003eEnsure all artifacts are in place as needed such as a Computer Matching Agreement (CMA), Information Exchange Agreements (IEA), or any other agreement when sharing information.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDepending on the structure of your specific team, some System/Business Owner responsibilities will be completed by the trained ISSO. Alternatively, some teams may utilize their System/Business Owner to complete ISSO tasks. Your team will decide what structure works best for your unique needs.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCMS Privacy Advisor\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Privacy Advisor has in-depth knowledge of privacy risks and can help your team meet the requirements for your PIA. The Privacy Advisor will complete the following tasks:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview component PIAs for accuracy, consistency and compliance; coordinating with the Cyber Risk Advisor (CRA) to identify any outstanding privacy risks prior to submission to the CMS SOP.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEnsure answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCheck each PIA for other Privacy-related requirements (e.g. Privacy Act implications).\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview and edit each PIA for grammatical mistakes or incomplete responses.\u0026nbsp;\u003c/li\u003e\u003cli\u003eProvide input and guidance as needed regarding any other privacy weaknesses as identified.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Cyber Risk Advisor (CRA)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CRA is responsible for coordinating the drafting and review process of the PIA with the CMS office or center in which they are representing. The CRA will:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eCommunicate with System/Business Owners through the authorization process, and ensure that the PIA is included in the authorization package.\u003c/li\u003e\u003cli\u003eReview PIAs submitted by the ISSO or System Owner for potential security and privacy risk, this can include:\u003cul\u003e\u003cli\u003eChecking that information in the PIA matches other artifacts in the ATO package as needed, including checking for grammatical mistakes or incomplete responses.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEnsuring the answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eCoordinate with the Privacy Advisor to identify any potential privacy risks during the review of the PIA.\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview PIAs sent back from the SOP and/or HHS and coordinate with the ISSO and Privacy Advisor to resolve the outstanding comments as needed.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCoordinate with the Privacy Advisor to submit completed PIAs for approval to the CMS SOP.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Information System Security Officer (ISSO)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO provides oversight and develops documentation to ensure the completion of the Security Assessment and Authorization (SA\u0026amp;A) process for their information systems. The ISSO typically performs this function on behalf of the System/Business Owner for the FISMA system. The PIA is included as one of the artifacts in the Security Assessment and Authorization package. The ISSO will:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDraft a new PIA or modify a PIA in coordination with the System Owner and CRA to address major changes or PIA requirements.\u003c/li\u003e\u003cli\u003eContact the CRA to obtain either HHS or CMS PIA guidance when required.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEngage with the System/Business Owner, CRA, Privacy Advisor, and CMS leadership to ensure all comments and suggestions are included in the PIA\u003c/li\u003e\u003cli\u003eAssist in identifying and remediating potential privacy risks and notify System/Business Owners of PIA requirements;\u0026nbsp;\u0026nbsp;\u003c/li\u003e\u003cli\u003eInform the CRA when a planned, new or existing system will require a PIA\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eSteps for completing your PIA\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe Department of Health and Human Services (HHS) issues the master guidance for completing PIAs. ISPG has taken the guidance provided by HHS and translated it into a questionnaire found on\u003ca href=\"https://cfacts.cms.gov/apps/ArcherApp/Home.aspx\"\u003e CFACTS\u003c/a\u003e. ISSOs can log in to CFACTS to complete the questionnaire with guidance from the System/Business Owner and the assigned Cyber Risk Advisor (CRA). A step-by-step guide to answering the questions required to complete the PIA can be found within the PIA \u0026amp; PTA Writer’s Handbook, which is written by HHS and can be found as a resource on the front page of each question in CFACTS. If you would like a copy of the PIA \u0026amp; PTA Writers Handbook, please contact the Privacy Office. The procedures below give a summary review of the actions necessary to complete a new PIA or modify an existing PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 1: PIA initial draft\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: SO/BO, ISSO, Cyber Risk Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eFollowing any of the scenarios or major changes that would require the completion of a PIA, the System/Business Owner works with the ISSO to draft a new or revised PIA in CFACTS. Upon completion of the new or revised PIA, the System/Business Owner or ISSO will contact the CRA for review. In CFACTS, the queue for the System/Business owner or ISSO is “ISSO Submitter” for the PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 2: PIA review / revision\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: CRA, Privacy Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe CRA reviews the PIA in collaboration with the Privacy Advisor and coordinates recommended changes with the system/business owner or ISSO. Any identified privacy risks or compliance issues should be resolved before submission to the SOP for approval. If the SOP or SAOP recommends changes, the review process will return to this step as needed until the PIA is approved and finalized by the Senior Agency Official for Privacy (SAOP).\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 3: PIA approval\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: CMS Senior Official for Privacy (SOP), Final Approver\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SOP or designated Final Approver will review the PIA and recommend approval to HHS if no changes are recommended.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 4: PIA signing\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: Senior Agency Official for Privacy (SAOP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SAOP will designate staff to review all PIAs before approval for signature. If no changes are recommended, the SOP and SAOP will digitally sign the PIA. Once signed by the SOP and SAOP, the PIA is approved and complete for a length of time as discussed above.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 5: PIA posting\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: Senior Agency Official for Privacy (SAOP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SAOP will send the completed PIA to HHS\u003cstrong\u003e. \u003c/strong\u003eHHS will submit the final PIA for publication to the HHS PIA internet site at\u003ca href=\"https://www.hhs.gov/pia\"\u003e https://www.hhs.gov/pia\u003c/a\u003e.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eTips for completing your PIA\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBefore starting to fill out your PIA, obtain and review any available program and system documentation. This may include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eWebsites that explain the service or business process supported by the system;\u003c/li\u003e\u003cli\u003eInformation Collection Requests (ICRs) if the system collects information from the public and is subject to the Paperwork Reduction Act (PRA); if unsure, please reach out to the PRA office.\u0026nbsp;\u003c/li\u003e\u003cli\u003ePrivacy Act Statements (PASs) and System of Records Notices (SORNs) if records in the system are subject to the Privacy Act;\u003c/li\u003e\u003cli\u003eAgency IT Portfolio Summaries (formerly called Exhibit 53s) or any Major IT Investment Business Cases (formerly called Exhibit 300s);\u003c/li\u003e\u003cli\u003eEnterprise Program Lifecycle Artifacts such as a System Security and Privacy Plan (SSPP); and\u003c/li\u003e\u003cli\u003eAny handbooks or other guidance on how to use the system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIt may be possible to reuse language from these documents to respond to questions. However, make sure you review all copied text to verify that it is specific to the system being reviewed, is complete, and makes sense absent the rest of the document. Text copied from marketing materials and system planning documents may discuss functions that were never purchased or implemented. Text copied from a SORN or budget document may describe more than one system.\u003c/p\u003e\u003cp\u003eThe purpose of a PIA is to provide the general public with information about how CMS systems collect and share user data. The general public is the audience for PIAs, so it’s essential to keep your end users in mind when drafting your PIA.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eAnswer each question briefly; text fields have a limited capacity when translated to the final documentation in CFACTS\u003c/li\u003e\u003cli\u003eWrite in a way that is easily understood by the general public; avoid using overly technical language, and clearly define technical terms and references if needed to describe a system.\u003c/li\u003e\u003cli\u003eDefine each acronym the first time it is used; use the acronym alone in all subsequent references.\u003c/li\u003e\u003cli\u003eDo not include sensitive or confidential system information or information that could allow a potential threat source to gain unauthorized access into the system (e.g., do not provide detailed information on technical security controls)\u003c/li\u003e\u003cli\u003eProvide information about authentication credentials. Reviewers need to know if the system is accessed using system-specific login information such as a username and password or if the system uses only PIV access and single sign-on authentication. The login method determines how user credentials are stored outside the system boundary. Please include a statement indicating whether login information is stored in the system.\u003c/li\u003e\u003cli\u003eMake it clear who the “users” are for your system. In some cases, it may be confusing whether “users” refers to individuals creating records about themselves or whether “users” are CMS staff members receiving and acting on this information. Please make this distinction clear the first time the term “users” is used. If contractors are listed as users, please cite if contractors are “direct” or “indirect”.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eGuidance for specific PIA questions\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCompleting a Privacy Impact Assessment (PIA) can be a challenge. It’s essential to provide all the relevant information while ensuring it is correct and up to date. The following guidance comes from the Privacy Office, as well as a number of ISSOs and System/Business Owners who have experience completing successful PIAs in CFACTS.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eFor PIA question 6b, make sure the ISSO information is correct and up to date.\u003c/li\u003e\u003cli\u003eWhen answering question 10, consider all changes that have occurred since the PIA was last finalized, as well as the changes that will occur when the PIA is finalized. All changes, whether or not they pose a new privacy risk, should be documented. Examples of changes include changing the physical location of a server or adding additional collection of new PII elements.\u003c/li\u003e\u003cli\u003eFor PIA question 11, you should include what HHS functions are supported by the system and how the system completes those functions. Your response should be concise and specific, and should not contain jargon or overly technical terms so that a reader with no prior knowledge of the system will understand the response. Don’t forget to spell out all acronyms on first usage.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor PIA question 12, list and describe all types of information collected by the system regardless of whether that information is considered PII. Make sure to include how long information is stored in the system. If the system holds system-specific access credentials, e.g., username, password, please describe those components in the response to this question. Specify whether the username and/or password are created by the individual, generated by the system, provided by a system administrator, or established through some other process.\u0026nbsp; Reminder: Any types of PII listed in this response also need to be listed in PIA question 15.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor PIA question 12, describe why the information listed in the question is collected. The response to this question should consider all information, whether or not it is PII. The response to this question should also specify what information is collected about each category of individual and should document and discuss if records are retrieved by PII elements.\u003c/li\u003e\u003cli\u003eFor PIA question13, include a brief description of the method of record retrieval, if you answered “Yes'' to PIA question 22 regarding System of Record Notification (SORN). Note the PII used and categories of individuals to whom the PII relates.\u0026nbsp;\u003cul\u003e\u003cli\u003eAn example is: The Physical Security System (PSS) regularly uses PII to retrieve system records including using the last name, employee ID number, and/or work phone number of CMS employees, contractors, and members of the public authorized to access the main campus and satellite offices.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003ePIA question 14 is calculated by the system. Reminder: If the response to this question is No, PIA questions 15 through 38 should no longer appear on the form.\u0026nbsp;\u003c/li\u003e\u003cli\u003eIf PIA question 15 is shown, check all the boxes that apply. If the information collected by the system is not described by any of the items in the list, there is a text field under ‘Other’ where you can list additional information. Your response should include all types of PII regardless of type sensitivity, or whether it is from employees or the public. Reminder: PII elements need to be accounted for in both PIA question 12 and PIA question 15.\u003c/li\u003e\u003cli\u003ePIA question 20 should describe all the ways Social Security Numbers (SSNS) are used in the system (if applicable). You’ll need to share when, where, and why an SSN is disclosed or shared; and why the SSN is used rather than another identifier.\u0026nbsp;\u003cul\u003e\u003cli\u003eNOTE: Employer Identification Number (EIN) also known as Federal Employer Identification Number (FEIN) or Tax Identification Number (TIN) or Federal Tax Identification Number (FTIN).\u0026nbsp; Individuals may choose to use their SSN as their EIN or FTIN. Typically, this would be sole proprietors or other small business owners who use SSN as EIN for tax purposes. EIN often appears in the format XX-XXXXXXX and may not stand out as a SSN. Any time that Social Security Numbers are involved, examine whether the collection and/or use of the SSN can be eliminated.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003eReminder: If the response to this question states that SSNs are collected, SSNs should also be listed in the response to PIA question 15.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePIA question 21 asks for the legal authorities governing information collection. Every system with PII must have an authority to collect this information. This will be a statute or Executive Order that either (a) permits or requires collection of the PII, or (b) permits or requires the underlying activity, for which it is necessary to collect PII.\u003c/li\u003e\u003cli\u003ePIA questions 22 and 22a are relevant to System of Record Notifications (SORNs). If the\u003c/li\u003e\u003cli\u003esystem uses PII to retrieve records, it may need to be covered by a SORN. Any system that has already received Privacy Office signatures should already reference a SORN. If not, you may need to seek guidance from ISPG or DSPPG to determine whether a SORN is required and in identifying an existing SORN that might apply. Please also review your response to PIA question 13 to ensure that it matches with your response here in question 22.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEach system has unique functions and answers to questions will be different for different systems. Question 23 determines whether your system needs an Information Collection Approval number from the White House Office of Management and Budget (OMB). In some cases, when you answer question 23, question 23a will appear. It asks about an OMB Information Collection Approval number. Under the Paperwork Reduction Act (PRA), the System/Business Owner or ISSO may need to obtain an information collection approval number from the OMB. Use the information in the CMS guidance and HHS PIA Writers’ Handbook regarding this question to contact subject matter experts as needed.\u003c/li\u003e\u003cli\u003eFor PIA question 27, please state that any system that utilizes information obtained from the Enterprise Portal (EIDM) must provide individuals the option to opt-out of information sharing. And similar to PIA question 25, if EIDM has its own PIA for CMS please add this statement.\u003c/li\u003e\u003cli\u003eFor PIA question 29, Identify System Acronym\u003c/li\u003e\u003cli\u003eFor PIA question 37, NARA Disposition Schedule ID, and the retention period described by the schedule, should be included\u003c/li\u003e\u003cli\u003ePIA question 37 asks about the system retention schedule. Every system (whether it contains PII or not) should have been made subject to an information retention schedule. Check with the Records Officer to identify the appropriate retention schedule.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"1d5:T5673,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is the purpose of a Privacy Impact Assessment (PIA)?\u0026nbsp;\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Privacy Impact Assessment (PIA) is an analysis of how personally identifiable information (PII) is collected, used, shared, and maintained. The purpose of a PIA is to demonstrate that system owners have consciously incorporated privacy protections within their systems for information supplied for by the public.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePIAs are required by the E-Government Act of 2002, which was enacted by Congress in order to improve the management of Federal electronic government services and processes. Section 208 of the E-Government Act specifically requires PIAs to be created when a federal agency develops or procures new information technology that involves the collection, maintenance, or dissemination of information in identifiable form.\u003c/p\u003e\u003cp\u003eFurther, because the E-Government Act also includes a provision requiring PIAs to be published publicly on agency websites, they allow CMS to communicate more clearly with the public about how we handle information, including how we address privacy concerns and safeguard information. Copies of completed PIAs are\u003ca href=\"https://www.hhs.gov/pia/index.html\"\u003e posted on the HHS website\u003c/a\u003e upon completion to offer transparency to the public.\u003c/p\u003e\u003cp\u003ePIAs must be completed in the following situations:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eFor all new systems that collect PII from 10 or more members of the general public, a PIA is required to be completed as part of the broader Authority to Operate (ATO) process.\u003c/li\u003e\u003cli\u003eFor every existing system that collects PII from 10 or more members of the general public, a PIA must be reviewed and re-approved once every three years. System/Business Owners and Information System Security Officers (ISSOs) must review and revise as necessary, and submit PIAs for re-approval no later than three years from the last HHS approval date.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor any existing system undergoing a \u003cstrong\u003emajor change\u003c/strong\u003e, an updated PIA is required.\u003c/li\u003e\u003cli\u003eAn existing system that is going through the ATO process may need to update their PIA paperwork if it’s close to expiring; an ATO cannot be completed with an expired or incomplete PIA.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIf your FISMA system does not meet the requirements above, it may not require a traditional PIA. In these instances, there may be other Privacy compliance requirements for your system or application. For example, you may be required to complete a different type of assessment (such as a Privacy Threshold Analysis (PTA), Third Party Website Application (TPWA) Privacy Impact Assessment, or Internal Privacy Impact Assessment).\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePIA roles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003ch3\u003e\u003cstrong\u003eHHS Chief Information Officer (CIO)/Senior Agency Official for Privacy (SAOP)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAt HHS, the Chief Information Officer (CIO) is designated as the Senior Agency Official for Privacy (SAOP) and provides the overall program structure for the completion of PIAs across all operating divisions. Responsibilities for the SAOP include, but are not limited to the following:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDevelop a standard form for HHS PIAs\u003c/li\u003e\u003cli\u003eReview PIAs from all operating divisions for adequacy, consistency, and compliance with federal and HHS requirements\u003c/li\u003e\u003cli\u003eIf the PIA meets HHS’s requirements, the PIA is signed by the SAOP, which finalizes the PIA for a period depending on the type of PIA\u003c/li\u003e\u003cli\u003eEnsure all PIAs are published and made publicly available on HHS.gov\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Senior Official for Privacy (SOP)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAt CMS, the Senior Official for Privacy (SOP) is the lead privacy official responsible for administering the agency PIA process and providing direction for the CMS privacy program. Unresolved privacy risks and other potential issues should be addressed before submission to the CMS SOP for final review. Responsibilities of the CMS SOP include, but are not limited to the following:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eEstablish a CMS specific framework for the development and completion of PIAs in accordance with federal and HHS requirements\u003c/li\u003e\u003cli\u003eReview and approve all PIAs for completion and consistency prior to submission to the HHS SAOP in coordination with the CMS Final Approver\u003c/li\u003e\u003cli\u003eSigning the PIA on behalf of CMS once the PIA satisfies federal and HHS requirements (The PIA will still require HHS’s final signature before publication to the HHS website)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS System Owner/Business Owner\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eInformation System Owners or Business Owners are individuals who are responsible for CMS FISMA systems or electronic information collections. System/Business Owners:\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview, revise, and submit PIAs for approval for new systems or re-approval whenever a change to an IT system, a change in CMS practice, or another factor alters the privacy risks associated with the use of the IT system or electronic information collection.\u0026nbsp;\u003c/li\u003e\u003cli\u003eAllocate proper resources to permit identification and remediation of privacy risks and weaknesses identified on PIAs.\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview, revise, and submit PIAs for re-approval three years from the last approval date, and as part of the authorization process as required.\u0026nbsp;\u003c/li\u003e\u003cli\u003eComply with all relevant Privacy Act requirements regarding any system of records, including, but not limited to, providing individuals with procedures for access and amendment of records.\u003c/li\u003e\u003cli\u003eEnsure all artifacts are in place as needed such as a Computer Matching Agreement (CMA), Information Exchange Agreements (IEA), or any other agreement when sharing information.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDepending on the structure of your specific team, some System/Business Owner responsibilities will be completed by the trained ISSO. Alternatively, some teams may utilize their System/Business Owner to complete ISSO tasks. Your team will decide what structure works best for your unique needs.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCMS Privacy Advisor\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Privacy Advisor has in-depth knowledge of privacy risks and can help your team meet the requirements for your PIA. The Privacy Advisor will complete the following tasks:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview component PIAs for accuracy, consistency and compliance; coordinating with the Cyber Risk Advisor (CRA) to identify any outstanding privacy risks prior to submission to the CMS SOP.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEnsure answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCheck each PIA for other Privacy-related requirements (e.g. Privacy Act implications).\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview and edit each PIA for grammatical mistakes or incomplete responses.\u0026nbsp;\u003c/li\u003e\u003cli\u003eProvide input and guidance as needed regarding any other privacy weaknesses as identified.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Cyber Risk Advisor (CRA)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CRA is responsible for coordinating the drafting and review process of the PIA with the CMS office or center in which they are representing. The CRA will:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eCommunicate with System/Business Owners through the authorization process, and ensure that the PIA is included in the authorization package.\u003c/li\u003e\u003cli\u003eReview PIAs submitted by the ISSO or System Owner for potential security and privacy risk, this can include:\u003cul\u003e\u003cli\u003eChecking that information in the PIA matches other artifacts in the ATO package as needed, including checking for grammatical mistakes or incomplete responses.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEnsuring the answers provided in the PIA are consistent with the HHS PTA and PIA Writers Handbook.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eCoordinate with the Privacy Advisor to identify any potential privacy risks during the review of the PIA.\u0026nbsp;\u003c/li\u003e\u003cli\u003eReview PIAs sent back from the SOP and/or HHS and coordinate with the ISSO and Privacy Advisor to resolve the outstanding comments as needed.\u0026nbsp;\u003c/li\u003e\u003cli\u003eCoordinate with the Privacy Advisor to submit completed PIAs for approval to the CMS SOP.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Information System Security Officer (ISSO)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO provides oversight and develops documentation to ensure the completion of the Security Assessment and Authorization (SA\u0026amp;A) process for their information systems. The ISSO typically performs this function on behalf of the System/Business Owner for the FISMA system. The PIA is included as one of the artifacts in the Security Assessment and Authorization package. The ISSO will:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDraft a new PIA or modify a PIA in coordination with the System Owner and CRA to address major changes or PIA requirements.\u003c/li\u003e\u003cli\u003eContact the CRA to obtain either HHS or CMS PIA guidance when required.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEngage with the System/Business Owner, CRA, Privacy Advisor, and CMS leadership to ensure all comments and suggestions are included in the PIA\u003c/li\u003e\u003cli\u003eAssist in identifying and remediating potential privacy risks and notify System/Business Owners of PIA requirements;\u0026nbsp;\u0026nbsp;\u003c/li\u003e\u003cli\u003eInform the CRA when a planned, new or existing system will require a PIA\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eSteps for completing your PIA\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe Department of Health and Human Services (HHS) issues the master guidance for completing PIAs. ISPG has taken the guidance provided by HHS and translated it into a questionnaire found on\u003ca href=\"https://cfacts.cms.gov/apps/ArcherApp/Home.aspx\"\u003e CFACTS\u003c/a\u003e. ISSOs can log in to CFACTS to complete the questionnaire with guidance from the System/Business Owner and the assigned Cyber Risk Advisor (CRA). A step-by-step guide to answering the questions required to complete the PIA can be found within the PIA \u0026amp; PTA Writer’s Handbook, which is written by HHS and can be found as a resource on the front page of each question in CFACTS. If you would like a copy of the PIA \u0026amp; PTA Writers Handbook, please contact the Privacy Office. The procedures below give a summary review of the actions necessary to complete a new PIA or modify an existing PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 1: PIA initial draft\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: SO/BO, ISSO, Cyber Risk Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eFollowing any of the scenarios or major changes that would require the completion of a PIA, the System/Business Owner works with the ISSO to draft a new or revised PIA in CFACTS. Upon completion of the new or revised PIA, the System/Business Owner or ISSO will contact the CRA for review. In CFACTS, the queue for the System/Business owner or ISSO is “ISSO Submitter” for the PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 2: PIA review / revision\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: CRA, Privacy Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe CRA reviews the PIA in collaboration with the Privacy Advisor and coordinates recommended changes with the system/business owner or ISSO. Any identified privacy risks or compliance issues should be resolved before submission to the SOP for approval. If the SOP or SAOP recommends changes, the review process will return to this step as needed until the PIA is approved and finalized by the Senior Agency Official for Privacy (SAOP).\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 3: PIA approval\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: CMS Senior Official for Privacy (SOP), Final Approver\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SOP or designated Final Approver will review the PIA and recommend approval to HHS if no changes are recommended.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 4: PIA signing\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: Senior Agency Official for Privacy (SAOP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SAOP will designate staff to review all PIAs before approval for signature. If no changes are recommended, the SOP and SAOP will digitally sign the PIA. Once signed by the SOP and SAOP, the PIA is approved and complete for a length of time as discussed above.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eStep 5: PIA posting\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003ePrimary Responsibility: Senior Agency Official for Privacy (SAOP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe SAOP will send the completed PIA to HHS\u003cstrong\u003e. \u003c/strong\u003eHHS will submit the final PIA for publication to the HHS PIA internet site at\u003ca href=\"https://www.hhs.gov/pia\"\u003e https://www.hhs.gov/pia\u003c/a\u003e.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eTips for completing your PIA\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBefore starting to fill out your PIA, obtain and review any available program and system documentation. This may include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eWebsites that explain the service or business process supported by the system;\u003c/li\u003e\u003cli\u003eInformation Collection Requests (ICRs) if the system collects information from the public and is subject to the Paperwork Reduction Act (PRA); if unsure, please reach out to the PRA office.\u0026nbsp;\u003c/li\u003e\u003cli\u003ePrivacy Act Statements (PASs) and System of Records Notices (SORNs) if records in the system are subject to the Privacy Act;\u003c/li\u003e\u003cli\u003eAgency IT Portfolio Summaries (formerly called Exhibit 53s) or any Major IT Investment Business Cases (formerly called Exhibit 300s);\u003c/li\u003e\u003cli\u003eEnterprise Program Lifecycle Artifacts such as a System Security and Privacy Plan (SSPP); and\u003c/li\u003e\u003cli\u003eAny handbooks or other guidance on how to use the system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIt may be possible to reuse language from these documents to respond to questions. However, make sure you review all copied text to verify that it is specific to the system being reviewed, is complete, and makes sense absent the rest of the document. Text copied from marketing materials and system planning documents may discuss functions that were never purchased or implemented. Text copied from a SORN or budget document may describe more than one system.\u003c/p\u003e\u003cp\u003eThe purpose of a PIA is to provide the general public with information about how CMS systems collect and share user data. The general public is the audience for PIAs, so it’s essential to keep your end users in mind when drafting your PIA.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eAnswer each question briefly; text fields have a limited capacity when translated to the final documentation in CFACTS\u003c/li\u003e\u003cli\u003eWrite in a way that is easily understood by the general public; avoid using overly technical language, and clearly define technical terms and references if needed to describe a system.\u003c/li\u003e\u003cli\u003eDefine each acronym the first time it is used; use the acronym alone in all subsequent references.\u003c/li\u003e\u003cli\u003eDo not include sensitive or confidential system information or information that could allow a potential threat source to gain unauthorized access into the system (e.g., do not provide detailed information on technical security controls)\u003c/li\u003e\u003cli\u003eProvide information about authentication credentials. Reviewers need to know if the system is accessed using system-specific login information such as a username and password or if the system uses only PIV access and single sign-on authentication. The login method determines how user credentials are stored outside the system boundary. Please include a statement indicating whether login information is stored in the system.\u003c/li\u003e\u003cli\u003eMake it clear who the “users” are for your system. In some cases, it may be confusing whether “users” refers to individuals creating records about themselves or whether “users” are CMS staff members receiving and acting on this information. Please make this distinction clear the first time the term “users” is used. If contractors are listed as users, please cite if contractors are “direct” or “indirect”.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eGuidance for specific PIA questions\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCompleting a Privacy Impact Assessment (PIA) can be a challenge. It’s essential to provide all the relevant information while ensuring it is correct and up to date. The following guidance comes from the Privacy Office, as well as a number of ISSOs and System/Business Owners who have experience completing successful PIAs in CFACTS.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eFor PIA question 6b, make sure the ISSO information is correct and up to date.\u003c/li\u003e\u003cli\u003eWhen answering question 10, consider all changes that have occurred since the PIA was last finalized, as well as the changes that will occur when the PIA is finalized. All changes, whether or not they pose a new privacy risk, should be documented. Examples of changes include changing the physical location of a server or adding additional collection of new PII elements.\u003c/li\u003e\u003cli\u003eFor PIA question 11, you should include what HHS functions are supported by the system and how the system completes those functions. Your response should be concise and specific, and should not contain jargon or overly technical terms so that a reader with no prior knowledge of the system will understand the response. Don’t forget to spell out all acronyms on first usage.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor PIA question 12, list and describe all types of information collected by the system regardless of whether that information is considered PII. Make sure to include how long information is stored in the system. If the system holds system-specific access credentials, e.g., username, password, please describe those components in the response to this question. Specify whether the username and/or password are created by the individual, generated by the system, provided by a system administrator, or established through some other process.\u0026nbsp; Reminder: Any types of PII listed in this response also need to be listed in PIA question 15.\u0026nbsp;\u003c/li\u003e\u003cli\u003eFor PIA question 12, describe why the information listed in the question is collected. The response to this question should consider all information, whether or not it is PII. The response to this question should also specify what information is collected about each category of individual and should document and discuss if records are retrieved by PII elements.\u003c/li\u003e\u003cli\u003eFor PIA question13, include a brief description of the method of record retrieval, if you answered “Yes'' to PIA question 22 regarding System of Record Notification (SORN). Note the PII used and categories of individuals to whom the PII relates.\u0026nbsp;\u003cul\u003e\u003cli\u003eAn example is: The Physical Security System (PSS) regularly uses PII to retrieve system records including using the last name, employee ID number, and/or work phone number of CMS employees, contractors, and members of the public authorized to access the main campus and satellite offices.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003ePIA question 14 is calculated by the system. Reminder: If the response to this question is No, PIA questions 15 through 38 should no longer appear on the form.\u0026nbsp;\u003c/li\u003e\u003cli\u003eIf PIA question 15 is shown, check all the boxes that apply. If the information collected by the system is not described by any of the items in the list, there is a text field under ‘Other’ where you can list additional information. Your response should include all types of PII regardless of type sensitivity, or whether it is from employees or the public. Reminder: PII elements need to be accounted for in both PIA question 12 and PIA question 15.\u003c/li\u003e\u003cli\u003ePIA question 20 should describe all the ways Social Security Numbers (SSNS) are used in the system (if applicable). You’ll need to share when, where, and why an SSN is disclosed or shared; and why the SSN is used rather than another identifier.\u0026nbsp;\u003cul\u003e\u003cli\u003eNOTE: Employer Identification Number (EIN) also known as Federal Employer Identification Number (FEIN) or Tax Identification Number (TIN) or Federal Tax Identification Number (FTIN).\u0026nbsp; Individuals may choose to use their SSN as their EIN or FTIN. Typically, this would be sole proprietors or other small business owners who use SSN as EIN for tax purposes. EIN often appears in the format XX-XXXXXXX and may not stand out as a SSN. Any time that Social Security Numbers are involved, examine whether the collection and/or use of the SSN can be eliminated.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003eReminder: If the response to this question states that SSNs are collected, SSNs should also be listed in the response to PIA question 15.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePIA question 21 asks for the legal authorities governing information collection. Every system with PII must have an authority to collect this information. This will be a statute or Executive Order that either (a) permits or requires collection of the PII, or (b) permits or requires the underlying activity, for which it is necessary to collect PII.\u003c/li\u003e\u003cli\u003ePIA questions 22 and 22a are relevant to System of Record Notifications (SORNs). If the\u003c/li\u003e\u003cli\u003esystem uses PII to retrieve records, it may need to be covered by a SORN. Any system that has already received Privacy Office signatures should already reference a SORN. If not, you may need to seek guidance from ISPG or DSPPG to determine whether a SORN is required and in identifying an existing SORN that might apply. Please also review your response to PIA question 13 to ensure that it matches with your response here in question 22.\u0026nbsp;\u003c/li\u003e\u003cli\u003eEach system has unique functions and answers to questions will be different for different systems. Question 23 determines whether your system needs an Information Collection Approval number from the White House Office of Management and Budget (OMB). In some cases, when you answer question 23, question 23a will appear. It asks about an OMB Information Collection Approval number. Under the Paperwork Reduction Act (PRA), the System/Business Owner or ISSO may need to obtain an information collection approval number from the OMB. Use the information in the CMS guidance and HHS PIA Writers’ Handbook regarding this question to contact subject matter experts as needed.\u003c/li\u003e\u003cli\u003eFor PIA question 27, please state that any system that utilizes information obtained from the Enterprise Portal (EIDM) must provide individuals the option to opt-out of information sharing. And similar to PIA question 25, if EIDM has its own PIA for CMS please add this statement.\u003c/li\u003e\u003cli\u003eFor PIA question 29, Identify System Acronym\u003c/li\u003e\u003cli\u003eFor PIA question 37, NARA Disposition Schedule ID, and the retention period described by the schedule, should be included\u003c/li\u003e\u003cli\u003ePIA question 37 asks about the system retention schedule. Every system (whether it contains PII or not) should have been made subject to an information retention schedule. Check with the Records Officer to identify the appropriate retention schedule.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"1d3:{\"value\":\"$1d4\",\"format\":\"body_text\",\"processed\":\"$1d5\",\"summary\":\"\"}\n1d8:[]\n1d7:{\"uri\":\"entity:node/206\",\"title\":\"Authorization to Operate (ATO) \",\"options\":\"$1d8\",\"url\":\"/learn/authorization-operate-ato\"}\n1da:[]\n1d9:{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security and Privacy Policy (IS2P2)\",\"options\":\"$1da\",\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"}\n1dc:[]\n1db:{\"uri\":\"https://www.hhs.gov/pia/index.html\",\"title\":\"HHS Privacy Impact Assessment (PIA) information\",\"options\":\"$1dc\",\"url\":\"https://www.hhs.gov/pia/index.html\"}\n1d6:[\"$1d7\",\"$1d9\",\"$1db\"]\n1dd:{\"value\":\"Information, tips, and tricks for writing your Privacy Impact Assessment (PIA) concisely and correctly\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eInformation, tips, and tricks for writing your Privacy Impact Assessment (PIA) concisely and correctly\u003c/p\u003e\\n\"}\n1d1:{\"drupal_internal__nid\":421,\"drupal_internal__vid\":5561,\"langcode\":\"en\",\"revision_timestamp\":\"2024-06-07T20:11:35+00:00\",\"status\":true,\"title\":\"CMS Privacy Impact Assessment (PIA) Handbook\",\"created\":\"2022-08-29T17:13:40+00:00\",\"changed\":\"2024-06-06T17:47:05+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":\"$1d2\",\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":\"$1d3\",\"field_contact_email\":\"privacy@cms.hhs.gov\",\"field_contact_name\":\"Privacy Office\",\"field_last_reviewed\":\"2023-01-20\",\"field_related_resources\":\"$1d6\",\"field_short_description\":\"$1dd\"}\n1e1:{\"drupal_internal__target_id\":\"library\"}\n1e0:{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":\"$1e1\"}\n1e3:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/node_type?resourceVersion=id%3A5561\"}\n1e4:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/node_type?resourceVersion=id%3A5561\"}\n1"])</script><script>self.__next_f.push([1,"e2:{\"related\":\"$1e3\",\"self\":\"$1e4\"}\n1df:{\"data\":\"$1e0\",\"links\":\"$1e2\"}\n1e7:{\"drupal_internal__target_id\":110}\n1e6:{\"type\":\"user--user\",\"id\":\"a54cc91d-d38c-4158-9cf3-d7bcda34fc84\",\"meta\":\"$1e7\"}\n1e9:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/revision_uid?resourceVersion=id%3A5561\"}\n1ea:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/revision_uid?resourceVersion=id%3A5561\"}\n1e8:{\"related\":\"$1e9\",\"self\":\"$1ea\"}\n1e5:{\"data\":\"$1e6\",\"links\":\"$1e8\"}\n1ed:{\"drupal_internal__target_id\":26}\n1ec:{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":\"$1ed\"}\n1ef:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/uid?resourceVersion=id%3A5561\"}\n1f0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/uid?resourceVersion=id%3A5561\"}\n1ee:{\"related\":\"$1ef\",\"self\":\"$1f0\"}\n1eb:{\"data\":\"$1ec\",\"links\":\"$1ee\"}\n1f3:{\"drupal_internal__target_id\":91}\n1f2:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":\"$1f3\"}\n1f5:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/field_resource_type?resourceVersion=id%3A5561\"}\n1f6:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/field_resource_type?resourceVersion=id%3A5561\"}\n1f4:{\"related\":\"$1f5\",\"self\":\"$1f6\"}\n1f1:{\"data\":\"$1f2\",\"links\":\"$1f4\"}\n1fa:{\"drupal_internal__target_id\":66}\n1f9:{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":\"$1fa\"}\n1fc:{\"drupal_internal__target_id\":61}\n1fb:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":\"$1fc\"}\n1fe:{\"drupal_internal__target_id\":76}\n1fd:{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":\"$1fe\"}\n1f8:[\"$1f9\",\"$1fb\",\"$1fd\"]\n200:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084"])</script><script>self.__next_f.push([1,"b9a7e6f06/field_roles?resourceVersion=id%3A5561\"}\n201:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/field_roles?resourceVersion=id%3A5561\"}\n1ff:{\"related\":\"$200\",\"self\":\"$201\"}\n1f7:{\"data\":\"$1f8\",\"links\":\"$1ff\"}\n205:{\"drupal_internal__target_id\":16}\n204:{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":\"$205\"}\n207:{\"drupal_internal__target_id\":31}\n206:{\"type\":\"taxonomy_term--topics\",\"id\":\"d5e2c0ee-04cb-493b-9338-c97adf0e8adf\",\"meta\":\"$207\"}\n203:[\"$204\",\"$206\"]\n209:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/field_topics?resourceVersion=id%3A5561\"}\n20a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/field_topics?resourceVersion=id%3A5561\"}\n208:{\"related\":\"$209\",\"self\":\"$20a\"}\n202:{\"data\":\"$203\",\"links\":\"$208\"}\n1de:{\"node_type\":\"$1df\",\"revision_uid\":\"$1e5\",\"uid\":\"$1eb\",\"field_resource_type\":\"$1f1\",\"field_roles\":\"$1f7\",\"field_topics\":\"$202\"}\n1ce:{\"type\":\"node--library\",\"id\":\"ddb65a30-0e50-44c7-a6bd-084b9a7e6f06\",\"links\":\"$1cf\",\"attributes\":\"$1d1\",\"relationships\":\"$1de\"}\n20d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e?resourceVersion=id%3A4913\"}\n20c:{\"self\":\"$20d\"}\n20f:{\"alias\":\"/policy-guidance/cms-breach-response-handbook\",\"pid\":611,\"langcode\":\"en\"}\n211:T7b99,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook defines actions that must be taken in response to a suspected breach of Personally Identifiable Information (PII) / Protected Health Information (PHI) / Federal Tax Information (FTI) at the CMS to meet federal requirements for breach response. The handbook includes roles and responsibilities, breach response deliverables and lines of communication, triggers for federal reporting requirements, and resources from HHS and other authorities.\u003c/p\u003e\u003cp\u003eThese procedures help to ensure a coordinated response from all entities responsible for investigating and mitigating a breach, including organizations internal and external to CMS, as well as those responsible for remediating any identified process shortfalls.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eScope\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThese procedures apply to federal information and information systems, as defined in the \u003ca href=\"/learn/federal-information-systems-management-act-fisma\"\u003eFederal Information Security Modernization Act (FISMA)\u003c/a\u003e – but not to national security systems.\u003c/p\u003e\u003cp\u003eThis handbook covers breach response activities at CMS as an Operating Division (OpDiv) of the U.S. Department of Health and Human Services (HHS). It applies to CMS employees, contractors, grant recipients, interns, and affiliates supporting CMS. All organizations collecting or maintaining information or using or operating information systems on behalf of CMS also need to follow these procedures in accordance with such organizations’ contractual requirements to report to and cooperate with CMS during a breach.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eOut-of-scope entities\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eMedicare Advantage (Plans C and D) and State Medicaid programs are not CMS FISMA entities but are HIPAA-covered entities. These entities must honor their own reporting requirements.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho needs this handbook?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThis handbook is for all CMS stakeholders who may need to participate in or approve of breach response activities, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePersonnel at the CMS Cybersecurity Integration Center who support CMS Incident Response (IR)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003ePeople within CMS responsible for ensuring system security and privacy – such as System Owners (SO), Information System Security Officers (ISSO), and Cyber Risk Advisors (CRA)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003ePeople at HHS who must cooperate in or approve CMS actions, including the HHS Privacy Incident Response Team (PIRT)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS Security and Privacy stakeholders who are responsible for developing cyber defense and response systems and must describe the process ecosystem for their services\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eDefinitions for incidents and breaches\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eExact reporting requirements during a breach depend on the nature of the data affected by the breach. The Office of Management and Budget (OMB) has defined multiple types of security and privacy incidents within the scope of the Executive Branch. This section presents definitions of types of sensitive data and breach categories for use at CMS.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat counts as sensitive data?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB Memorandum M-17-12 prescribes that \u003cstrong\u003ePersonally Identifiable Information\u003c/strong\u003e refers to information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual. Because there are many different types of information that can distinguish or trace an individual’s identity, the term PII is necessarily broad.\u003c/p\u003e\u003cp\u003eThe Health Insurance Portability and Accountability Act (HIPAA) provides that \u003cstrong\u003eProtected Health Information\u003c/strong\u003e is personally identifiable health information. PHI is also PII.\u003c/p\u003e\u003cp\u003eInternal Revenue Service Publication 1075 prescribes that \u003cstrong\u003eFederal Tax Information\u003c/strong\u003e consists of federal tax returns and return information (and information derived from it) that is in an agency’s possession or control. FTI may contain PII.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat is an incident?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccording to the CMS Risk Management Handbook, an\u003cstrong\u003e incident\u003c/strong\u003e is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat is a breach?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB Memorandum M-17-12 stipulates that a \u003cstrong\u003ebreach\u003c/strong\u003e is a type of incident in which there is a loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence where either of these occurs:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA person other than an authorized user accesses or potentially accesses PII\u003c/li\u003e\u003cli\u003eAn authorized user accesses PII for an other-than-authorized purpose\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBreaches begin as incidents until incident responders determine that PII has been affected. Breach activities will often take place concurrently to ongoing incident response activities, such as containment, eradication, and recovery activities. For more information about Incident Response process, see the CMS Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003cp\u003eCMS will assess suspected breaches of PII to determine if they represent enough risk of harm to individuals whose data was compromised to require notification and mitigation.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eMajor incidents\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePer OMB Memorandum M-20-04, a \u003cstrong\u003emajor incident\u003c/strong\u003e is an incident that compromises U.S. national security. CMS does not store any data that, if breached, may impact national security. OMB also defines any unauthorized modification of, unauthorized deletion of, unauthorized exfiltration of, or unauthorized access to the PII of 100,000 or more people as a major incident. Major incidents must be reported to Congress within seven days.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eReporting incidents and breaches\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eIncident responders may determine during the incident response process, as more information about an incident is discovered, that the incident falls into other incident categories that trigger additional reporting requirements.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTable of reporting triggers\u003c/strong\u003e\u003c/h3\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eTrigger\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eRequirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eOutcome\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eAll Incidents\u003c/td\u003e\u003ctd\u003eNotify HHS, notify US-CERT (Computer Emergency Response Team)\u003c/td\u003e\u003ctd\u003eHHS is automatically notified by the CMS incident ticketing system; HHS handles reporting to US-CERT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAll Suspected or Confirmed Breaches\u003c/td\u003e\u003ctd\u003eConduct Risk Assessment\u003c/td\u003e\u003ctd\u003eIf the breach is not in a predefined low-risk category, the CMS Breach Analysis Team must convene.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eGreater than 500 individuals within same jurisdiction are affected by a breach\u003c/td\u003e\u003ctd\u003eNotify media in affected jurisdiction\u003c/td\u003e\u003ctd\u003eContact CMS Media Relations Group (MRG)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach indicates illegal activity\u003c/td\u003e\u003ctd\u003eContact Law Enforcement via HHS oversight body\u003c/td\u003e\u003ctd\u003eContact HHS Office of Inspector General (OIG) Computer Crimes Unit (CCU)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach affects FTI\u003c/td\u003e\u003ctd\u003eNotify IRS and Treasury Inspector General for Tax Administration\u003c/td\u003e\u003ctd\u003eContact CMS-IRS Liaison\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eGreater than 100,000 individuals are affected by the breach (Major Incident)\u003c/td\u003e\u003ctd\u003eNotify Congress within seven days\u003c/td\u003e\u003ctd\u003eContact Office of Legislation\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch3\u003e\u003cstrong\u003eAll incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll security and privacy incidents at CMS must be reported to the CMS Information Technology (IT) Service Desk.\u003c/p\u003e\u003cul\u003e\u003cli\u003ePhone: 410-786-2580 or 800-562-1963\u003c/li\u003e\u003cli\u003eEmail: \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe report should be made immediately upon discovery to start the CMS incident response process. The IT Service Desk instructs the reporter to fill out an incident report using the Incident Report Template – which is then sent to the Incident Management Team (IMT). Incidents must be reported whether they are confirmed to have occurred or are only suspected to have occurred. The Helpdesk refers security and privacy incidents to IMT, which then coordinates efforts to analyze, contain, and eradicate the incident.\u003c/p\u003e\u003cp\u003eAll incidents involving CMS must be reported to HHS to ensure that HHS can provide accurate incident statistics for its OpDivs as per FISMA requirements. By integrating CMS’s incident ticketing system with HHS, CMS automatically notifies HHS of incidents. More details on the CMS Incident Response capability and reporting requirements for incidents other than breaches can be found in the Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAll breaches\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Incident Management Team (IMT) investigates reported security and privacy incidents to determine if they meet the definition of a breach. The team does not need confirmation of a breach to begin the breach response process – they should treat incidents as breaches as soon as the investigation reveals that PII, PHI, or FTI was jeopardized by an incident.\u003c/p\u003e\u003cp\u003eIf an incident reaches the status of a suspected breach, IMT conducts a risk assessment on the suspected breach using the Risk Assessment Checklist. Then they notify the CMS Breach Analysis Team (BAT) that a suspected breach has occurred and provide the BAT with the results of the risk assessment.\u003c/p\u003e\u003cp\u003eThe BAT convenes to review the risk assessment and determine the likelihood of sensitive data compromise according to the CMS Breach Analysis Team Handbook. The team assigns the breach a risk rating of Low, Moderate, or High, and advises the affected system’s Business Owner (BO) on whether CMS must notify the affected individuals. Should notification be necessary, the Senior Official for Privacy (SOP) at CMS works with the following people to develop a notification and mitigation plan:\u003c/p\u003e\u003cul\u003e\u003cli\u003eBusiness Owner of the CMS system affected by the breach\u003c/li\u003e\u003cli\u003eContracting Officer’s Representative (COR) for any affected contractors\u003c/li\u003e\u003cli\u003eIncident responders\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDepending on the nature and quantity of the sensitive data compromised by the breach, different reporting requirements apply:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIf a breach compromises \u003cstrong\u003ePHI/PII\u003c/strong\u003e, the HIPAA Breach Notification Rule applies.\u003c/li\u003e\u003cli\u003eIf a breach compromises \u003cstrong\u003eFTI\u003c/strong\u003e, the IRS requires that the U.S. Treasury Inspector General for Tax Administration (TIGTA) be notified.\u003c/li\u003e\u003cli\u003eIf a breach compromises any data that may impact U.S. national security or otherwise meets the definition of a \u003cstrong\u003emajor incident\u003c/strong\u003e, then Congress must be notified.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eLow risk scenarios\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSome privacy incidents are considered low risk and do not rise to the threshold of a breach. The Data Governance Board (DGB) has defined a set of criteria for such incidents in the Data Governance Board Guidelines. The IMT can close out these breaches automatically if they represent a sufficiently low risk to not require convening a full Breach Analysis Team.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreaches of PHI\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS’s administration of Medicare and Medicaid make the agency a covered entity under HIPAA and subject to the law’s reporting and notification requirements when PHI is breached. This includes reporting to the HHS Office of Civil Rights (OCR) of all breaches of Protected Health Information (PHI) for each calendar year –\u0026nbsp; including those that occur with a business associate.\u003c/p\u003e\u003cp\u003eAny compromise of PHI requires CMS to notify the affected individual(s) within 60 days. If a breach affects the PHI of more than 500 residents of a U.S. state or jurisdiction, CMS is also “required to provide notice to prominent media outlets serving the State or jurisdiction,” and notify OCR within 60 days. The Breach Analysis Team must work with the CMS Office of Communication’s Media Relations Group to complete this notification step.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreaches of FTI\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Internal Revenue Service (IRS) requires organizations handling FTI (federal tax returns and return information, including information derived from a return) to report any unauthorized access to or disclosure of FTI to the Treasury Inspector General for Tax Administration and the IRS Office of Safeguards within 24 hours of identifying the incident.\u003c/p\u003e\u003cp\u003eIf the Incident Management Team (IMT)\u0026nbsp; determines that there is a possibility that FTI has been compromised by an incident, they should immediately notify the CMS IRS Liaison to begin the process for reporting to the IRS and TIGTA. Breach response stakeholders should be aware that IRS may request additional data and updates from CMS as the incident response process continues.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMajor incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB requires agencies to report major incidents to Congress within seven days. The threshold for a major incident is a breach that affects more than 100,000 individuals. As an HHS OpDiv, CMS will report major incidents to the HHS Computer Security Incident Response Center (CSIRC) to assist HHS in making a report to Congress. CMS will also report major incidents to the CMS Office of Legislation to ensure that the Office can coordinate with HHS on any participation by CMS in the report.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eBreach response steps and deliverables\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBreach response activities at CMS require robust lines of communication and clearly defined deliverables between multiple organizations and components, including CMS groups, contractors and associates, and HHS entities.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIn general, the communication responsibilities of CMS, HHS, and entities are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS will be responsible for collecting data pertaining to the breach, developing a plan for notifying persons affected by the breach and mitigating any resulting harm, and reporting all breach response activities to HHS.\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eHHS will be responsible for coordinating between CMS and external federal agencies, as well as approving any notification and mitigation plans developed by CMS.\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eEntities operating on behalf of CMS (contractors and associates) are responsible for implementing notification and mitigation plans created by CMS and approved by HHS.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBreach response activities take place in tandem with incident response activities. Discovery of new data about a breach should be reported as soon as possible to HHS Computer Security Incident Response Center (CSIRC), to ensure that HHS can meet its own reporting requirements. (HHS CSIRC is the primary communication pathway between CMS and external organizations such as other federal agencies.)\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS maintains an incident ticketing system that automatically sends ticket updates to a mirrored ticket in the equivalent HHS CSIRC ticketing system. Incident responders must maintain this integration and ensure that tickets are promptly updated to communicate with HHS.\u003c/p\u003e\u003cp\u003eThe Incident Management Team, in keeping with its role during incident response, is the primary communication pathway between organizations within CMS and its contractors and associates. For more details on IMT’s role and process during incidents, see the CMS Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003cp\u003eBreach response activities are accomplished through four stages: reporting, risk assessment, breach analysis, and notification and mitigation.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eReporting\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe incident ticket submitted by the CMS IT Helpdesk is the first notice to CMS of a possible breach. The IT Helpdesk works with the individual reporting an incident to create an initial \u003cstrong\u003eincident report as a deliverable\u003c/strong\u003e to the Incident Management Team (IMT) and create a ticket to track the issue. The incident ticket is automatically mirrored in the equivalent HHS system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRisk assessment\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIMT works with the affected system’s officials and operators to investigate the incident. They assess the incident to determine if any categories of sensitive data may be compromised. If there is a possibility of compromise, the incident is considered a suspected breach. IMT conducts a risk assessment using the “Factors for Assessing the Risk of Harm to Potentially Affected Individuals” prescribed by OMB and defined in the CMS Risk Assessment for Breach Notification Determination form. Then they formally convene the Breach Analysis Team and provide the team with the\u003cstrong\u003e IMT Risk Assessment as a deliverable.\u003c/strong\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreach analysis\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Breach Analysis Team convenes to review the IMT Risk Assessment and categorizes the risk represented by the breach as low, moderate, or high, as described in the CMS Breach Analysis Team Handbook.\u003c/p\u003e\u003cp\u003eThe BAT consists of breach response stakeholders in leadership positions and security and privacy subject matter experts for the affected system, including the Business Owner, ISSOs, COR (if the affected system is a contractor system), Senior Official for Privacy, and the DCTSO Incident Commander.\u003c/p\u003e\u003cp\u003eThe BAT determines if the conditions of the breach warrant notifying the affected individuals. If so, the BAT drafts a \u003cstrong\u003eNotification and Mitigation Plan as a deliverable\u003c/strong\u003e to the HHS Privacy Incident Response Team (PIRT), using the HHS PIRT Response Plan Template. The Business Owner of the affected system has the final decision on whether notification and mitigation will go forward.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNotification and mitigation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eHHS PIRT reviews the Notification and Mitigation Plan. The PIRT may overrule the BAT on whether notification and mitigation are necessary or they may request changes to the plan. If the PIRT approves, the Business Owner of the affected system (and the COR if the affected system is a contractor system) are responsible for executing the approved plan.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTable of breach response deliverables\u003c/strong\u003e\u003c/h3\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eBreach Response Deliverable\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eResponsible\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eDelivered To\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eIncident Report Ticket\u003c/td\u003e\u003ctd\u003eCMS IT Helpdesk\u003c/td\u003e\u003ctd\u003eIncident Management Team (IMT). IMT continues to update the ticket with information about the breach as the response proceeds.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk Assessment\u003c/td\u003e\u003ctd\u003eIncident Management Team\u003c/td\u003e\u003ctd\u003eBreach Analysis Team (BAT)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eNotification and Mitigation Plan\u003c/td\u003e\u003ctd\u003eBreach Analysis Team\u003c/td\u003e\u003ctd\u003eHHS Privacy Incident Response Team (PIRT)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach Notification to Affected Individuals\u003c/td\u003e\u003ctd\u003eSystem Business Owner / Contracting Officer’s Representative\u003c/td\u003e\u003ctd\u003eAffected individuals\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch2\u003e\u003cstrong\u003eBreach notification and mitigation\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe goal of breach response activities is to reduce the risk of harm to individuals that is created by a breach of sensitive data. If the Breach Analysis Team determines that a breach represents enough risk to individuals, they develop a Notification and Mitigation Plan.\u003c/p\u003e\u003cp\u003eThe CMS Senior Official for Privacy, in cooperation with the Business Owner of the affected system and with support from the full BAT, is responsible for developing the Notification and Mitigation Plan. CMS will receive approval to implement the plan from the HHS PIRT, using the HHS PIRT Response Plan Template as the formal deliverable. The Notification and Mitigation Plan must consider the nature and scope of the breach to determine if media organizations must be notified as per the HIPAA requirements.\u003c/p\u003e\u003cp\u003eOnce approved, the Notification and Mitigation Plan is implemented, with responsibility for implementation assigned to the Business Owner of the affected system (or the COR, if the affected system is a contractor system). If media notification is required, the BAT should coordinate with the CMS Media Relations Group (MRG).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNotification\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIf the Breach Analysis Team determines that a breach of PII represents a risk of harm to the affected individuals, then CMS must notify individuals whose PII is compromised in a breach. The team will develop a Notification and Mitigation Plan to describe the actions CMS will take to protect the affected individuals.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eIndividual notification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAs prescribed by the \u003ca href=\"/policy-guidance/breach-analysis-team-bat-handbook\"\u003eCMS Breach Analysis Team Handbook\u003c/a\u003e, the CMS Senior Official for Privacy works with the Business Owner of an affected CMS system to develop a notification letter describing the breach for individuals and submit it to HHS PIRT for approval.\u003c/p\u003e\u003cp\u003eOMB M-17-12 provides direction to federal agencies on what information should be included in breach notifications:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA brief description of what happened, including the date(s) of the breach and of its discovery\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA description of the types of sensitive data compromised by the breach (e.g., full name, Social Security Number, date of birth, home address, account number, and disability code), to the extent possible\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA statement of whether the information was encrypted or protected by other means, when it is determined that disclosing such information would be beneficial to potentially affected individuals and would not compromise the security of the information system\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eGuidance to potentially affected individuals on how they can mitigate their own risk of harm, the countermeasures undertaken, and any services provided to potentially affected individuals\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAny steps being taken to investigate the breach, to mitigate losses, and to protect against a future breach\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA description of how potentially affected individuals can learn more information about the breach, including a telephone number (preferably toll-free), email address, and postal address\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eHHS PIRT has oversight over CMS breach notification plans. After developing the notification letter and a plan to contact the affected individuals, the BAT should meet with HHS PIRT to gain approval to implement the plan. This meeting should also be attended by the Business Owner(s) of any affected CMS systems, the Contracting Officers of any CMS contractor partners who were involved in the breach, and the incident response personnel who investigated the breach to ensure that HHS PIRT can receive timely answers to any questions related to the breach.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eMedia notification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIn addition to individual notification, HIPAA requires CMS to notify local media outlets if a breach of PHI affects more than 500 individuals within a single locality.\u0026nbsp; The Breach Analysis Team should contact CMS Media Relations Group if a breach of PII/PHI affects more than 500 individuals to make certain that any plans to contact media outlets are included in the notification plan submitted to HHS PIRT for approval.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNotification through public CMS resources\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS must also consider that a widely publicized breach may cause members of the public to attempt to contact CMS with questions about the breach and inquire whether their own information was affected. As part of the notification plan, the Breach Analysis Team may determine that CMS should provide a public notification message on its public resources, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePosting on the cms.gov homepage to inform the public of the breach, with a link to further details\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eProviding CMS call centers with a message to play at the start of calls to inform callers how they can determine if they were affected by a breach\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eMitigation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAs part of its notification plan, the Breach Analysis Team must determine and document the actions that CMS will take to mitigate the risk of harm. If the breach puts the affected individuals at risk for identity theft, CMS will offer credit monitoring as prescribed by the CMS Breach Analysis Team Handbook.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eBudgeting considerations\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThere may be costs associated with implementing a notification and mitigation plan, such as providing a credit monitoring service free of charge to the affected individuals. If a contractor system is breached, the contractor should cover the costs of notification and mitigation. CMS contracts should establish this responsibility.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRoles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBreach response stakeholders have direct or supporting roles and responsibilities during a breach. Some stakeholders in this group are associated with the FISMA system undergoing a breach and some are part of the CMS incident response capability. The breach response stakeholders have the following roles and responsibilities:\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCMS FISMA System Stakeholders\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eBusiness Owner (BO)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns decision to notify individuals affected by a breach and provide mitigation, with advisement from the BAT.\u003c/li\u003e\u003cli\u003eOwns decision to take major actions impacting system availability in response to a breach (such as shutting down a breached system).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003ePrimary Information System Security Officer (ISSO)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrimary system stakeholder in charge of providing data to IMT, BAT, and other breach response stakeholders about the affected system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOperations Teams (to include General Support System [GSS] support)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eTakes incident response actions on the system affected by the breach. May escalate decision to take major action impacting availability to the BO.\u003c/li\u003e\u003cli\u003eProvides system data to IMT, BAT and other breach response stakeholders at the direction of the ISSO.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCyber Risk Adviser (CRA)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides guidance to breach response stakeholders on risk and compliance for the affected system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eISPG Breach Response and Coordination\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eCMS CISO\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the breach response process.\u003c/li\u003e\u003cli\u003eIs kept apprised of all developments during breach response, analysis, notification, and mitigation.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCMS Senior Official for Privacy (SOP)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the Breach Analysis Team process.\u003c/li\u003e\u003cli\u003eOwns and oversees the Notification and Mitigation Plan, in cooperation with the system BO.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDCTSO Incident Coordinator\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the incident response process.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Cybersecurity Integration Center (CCIC)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eIncident Management Team (IMT)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrimary coordination entity for breach response. Works to provide leadership (BAT, senior officials) with data about the breach to make decisions.\u003c/li\u003e\u003cli\u003eConducts initial analysis and risk assessment of breaches to provide to the BAT.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCMS Security Operations Center (SOC)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides technical support and security subject matter expertise to the BAT during a breach.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Subject Matter Expert Support\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eCMS Office of Communications/Media Relations Group\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides notification to media outlets in the event of a breach affecting the PHI of more than 500 individuals.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOffice of General Counsel\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides support to the BAT in the event of a major incident to help CMS prepare for congressional notification.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eBreach Analysis Team (BAT)\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003eOwns the risk decision (low/moderate/high) after IMT conducts a risk assessment.\u003c/li\u003e\u003cli\u003eWorks with the SOP and BO to advise on the Notification and Mitigation Plan.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eLaws and guidance\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eUse this list of applicable laws and guidance to learn more about the processes described in this handbook.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFederal laws\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.congress.gov/113/plaws/publ283/PLAW-113publ283.pdf\"\u003eFederal Information Security Modernization Act\u003c/a\u003e (FISMA) of 2014, Pub. L. 113-283, 128 Stat. 3073 (Dec. 18, 2014) (primarily codified at 44 U.S.C. chapter 35, subchapter 11).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.congress.gov/104/plaws/publ191/PLAW-104publ191.pdf\"\u003eHealth Insurance Portability and Accountability Act\u003c/a\u003e (HIPAA) of 1996, Pub. L. 104-191 (Aug. 21, 1996).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eExecutive orders, memoranda, and directives\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2017/m-17-12_0.pdf\"\u003eOMB Memorandum M-17-12\u003c/a\u003e, Preparing for and Responding to a Breach of Personally Identifiable Information (January 3, 2017).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.whitehouse.gov/wp-content/uploads/2019/11/M-20-04.pdf\"\u003eOMB Memorandum M-20-04\u003c/a\u003e, Fiscal Year 2019-2020 Guidance on Federal Information Security and Privacy Management Requirements (November 19, 2019).\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf\"\u003eOMB Circular A-130, Managing Information as a Strategic Resource\u003c/a\u003e (July 28, 2016).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/the-press-office/2016/07/26/annex-presidential-policy-directive-united-states-cyber-incident\"\u003ePPD-41, Annex for Presidential Policy Directive\u003c/a\u003e – United States Cyber Incident Coordination (July 26, 2016).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/memoranda/2016/m-16-14.pdf\"\u003eOMB Memorandum M-16-14, Category Management Policy 16-2\u003c/a\u003e: Providing Comprehensive Identity Protection Services, Identity Monitoring, and Data Breach Response (July 1, 2016).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS / HHS policy and procedures\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003eCMS Risk Management Handbook (RMH) Chapter 8: Incident Response\u003c/li\u003e\u003cli\u003eCMS Breach Analysis Team Handbook\u003c/li\u003e\u003cli\u003eData Governance Guidelines\u003c/li\u003e\u003cli\u003eHHS PIRT Response Plan Template\u003c/li\u003e\u003cli\u003eCMS Risk Assessment for Breach Notification Determination\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAdditional guidance\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eDepartment of Commerce / National Institute of Standards and Technology (NIST)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eNIST Special Publication 800-34 (Revision 1), \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf\"\u003eContingency Planning Guide for Federal Information Systems and Organizations\u003c/a\u003e (Apr. 2013).\u0026nbsp;\u003c/li\u003e\u003cli\u003eNIST Special Publication 800-61 (Revision 2), \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf\"\u003eComputer Security Incident Handling Guide\u003c/a\u003e (Aug. 2012).\u0026nbsp;\u003c/li\u003e\u003cli\u003eNIST Special Publication 800-122, \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf\"\u003eGuide to Protecting the Confidentiality of PII\u003c/a\u003e (Apr. 2010).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDepartment of Homeland Security (DHS) / United States Computer Emergency Readiness Team (US-CERT)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.cisa.gov/uscert/incident-notification-guidelines\"\u003eUS-CERT Federal Incident Notification Guidelines\u003c/a\u003e\u003c/li\u003e\u003cli\u003eNational Cybersecurity and Communications Integration Center (NCCIC) \u003ca href=\"https://www.cisa.gov/uscert/CISA-National-Cyber-Incident-Scoring-System\"\u003eCyber Incident Scoring System\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eGeneral Services Administration (GSA)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.gsa.gov/buy-through-us/products-services/professional-services/buy-services/identity-protection-services-ips\"\u003eIdentity Protection Services (IPS) Multiple Award Blanket Purchase Agreement (BPA)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"212:T7b99,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook defines actions that must be taken in response to a suspected breach of Personally Identifiable Information (PII) / Protected Health Information (PHI) / Federal Tax Information (FTI) at the CMS to meet federal requirements for breach response. The handbook includes roles and responsibilities, breach response deliverables and lines of communication, triggers for federal reporting requirements, and resources from HHS and other authorities.\u003c/p\u003e\u003cp\u003eThese procedures help to ensure a coordinated response from all entities responsible for investigating and mitigating a breach, including organizations internal and external to CMS, as well as those responsible for remediating any identified process shortfalls.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eScope\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThese procedures apply to federal information and information systems, as defined in the \u003ca href=\"/learn/federal-information-systems-management-act-fisma\"\u003eFederal Information Security Modernization Act (FISMA)\u003c/a\u003e – but not to national security systems.\u003c/p\u003e\u003cp\u003eThis handbook covers breach response activities at CMS as an Operating Division (OpDiv) of the U.S. Department of Health and Human Services (HHS). It applies to CMS employees, contractors, grant recipients, interns, and affiliates supporting CMS. All organizations collecting or maintaining information or using or operating information systems on behalf of CMS also need to follow these procedures in accordance with such organizations’ contractual requirements to report to and cooperate with CMS during a breach.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eOut-of-scope entities\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eMedicare Advantage (Plans C and D) and State Medicaid programs are not CMS FISMA entities but are HIPAA-covered entities. These entities must honor their own reporting requirements.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho needs this handbook?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThis handbook is for all CMS stakeholders who may need to participate in or approve of breach response activities, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePersonnel at the CMS Cybersecurity Integration Center who support CMS Incident Response (IR)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003ePeople within CMS responsible for ensuring system security and privacy – such as System Owners (SO), Information System Security Officers (ISSO), and Cyber Risk Advisors (CRA)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003ePeople at HHS who must cooperate in or approve CMS actions, including the HHS Privacy Incident Response Team (PIRT)\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eCMS Security and Privacy stakeholders who are responsible for developing cyber defense and response systems and must describe the process ecosystem for their services\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eDefinitions for incidents and breaches\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eExact reporting requirements during a breach depend on the nature of the data affected by the breach. The Office of Management and Budget (OMB) has defined multiple types of security and privacy incidents within the scope of the Executive Branch. This section presents definitions of types of sensitive data and breach categories for use at CMS.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat counts as sensitive data?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB Memorandum M-17-12 prescribes that \u003cstrong\u003ePersonally Identifiable Information\u003c/strong\u003e refers to information that can be used to distinguish or trace an individual’s identity, either alone or when combined with other information that is linked or linkable to a specific individual. Because there are many different types of information that can distinguish or trace an individual’s identity, the term PII is necessarily broad.\u003c/p\u003e\u003cp\u003eThe Health Insurance Portability and Accountability Act (HIPAA) provides that \u003cstrong\u003eProtected Health Information\u003c/strong\u003e is personally identifiable health information. PHI is also PII.\u003c/p\u003e\u003cp\u003eInternal Revenue Service Publication 1075 prescribes that \u003cstrong\u003eFederal Tax Information\u003c/strong\u003e consists of federal tax returns and return information (and information derived from it) that is in an agency’s possession or control. FTI may contain PII.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat is an incident?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccording to the CMS Risk Management Handbook, an\u003cstrong\u003e incident\u003c/strong\u003e is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat is a breach?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB Memorandum M-17-12 stipulates that a \u003cstrong\u003ebreach\u003c/strong\u003e is a type of incident in which there is a loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence where either of these occurs:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA person other than an authorized user accesses or potentially accesses PII\u003c/li\u003e\u003cli\u003eAn authorized user accesses PII for an other-than-authorized purpose\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBreaches begin as incidents until incident responders determine that PII has been affected. Breach activities will often take place concurrently to ongoing incident response activities, such as containment, eradication, and recovery activities. For more information about Incident Response process, see the CMS Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003cp\u003eCMS will assess suspected breaches of PII to determine if they represent enough risk of harm to individuals whose data was compromised to require notification and mitigation.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eMajor incidents\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePer OMB Memorandum M-20-04, a \u003cstrong\u003emajor incident\u003c/strong\u003e is an incident that compromises U.S. national security. CMS does not store any data that, if breached, may impact national security. OMB also defines any unauthorized modification of, unauthorized deletion of, unauthorized exfiltration of, or unauthorized access to the PII of 100,000 or more people as a major incident. Major incidents must be reported to Congress within seven days.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eReporting incidents and breaches\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eIncident responders may determine during the incident response process, as more information about an incident is discovered, that the incident falls into other incident categories that trigger additional reporting requirements.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTable of reporting triggers\u003c/strong\u003e\u003c/h3\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eTrigger\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eRequirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eOutcome\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eAll Incidents\u003c/td\u003e\u003ctd\u003eNotify HHS, notify US-CERT (Computer Emergency Response Team)\u003c/td\u003e\u003ctd\u003eHHS is automatically notified by the CMS incident ticketing system; HHS handles reporting to US-CERT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAll Suspected or Confirmed Breaches\u003c/td\u003e\u003ctd\u003eConduct Risk Assessment\u003c/td\u003e\u003ctd\u003eIf the breach is not in a predefined low-risk category, the CMS Breach Analysis Team must convene.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eGreater than 500 individuals within same jurisdiction are affected by a breach\u003c/td\u003e\u003ctd\u003eNotify media in affected jurisdiction\u003c/td\u003e\u003ctd\u003eContact CMS Media Relations Group (MRG)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach indicates illegal activity\u003c/td\u003e\u003ctd\u003eContact Law Enforcement via HHS oversight body\u003c/td\u003e\u003ctd\u003eContact HHS Office of Inspector General (OIG) Computer Crimes Unit (CCU)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach affects FTI\u003c/td\u003e\u003ctd\u003eNotify IRS and Treasury Inspector General for Tax Administration\u003c/td\u003e\u003ctd\u003eContact CMS-IRS Liaison\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eGreater than 100,000 individuals are affected by the breach (Major Incident)\u003c/td\u003e\u003ctd\u003eNotify Congress within seven days\u003c/td\u003e\u003ctd\u003eContact Office of Legislation\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch3\u003e\u003cstrong\u003eAll incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll security and privacy incidents at CMS must be reported to the CMS Information Technology (IT) Service Desk.\u003c/p\u003e\u003cul\u003e\u003cli\u003ePhone: 410-786-2580 or 800-562-1963\u003c/li\u003e\u003cli\u003eEmail: \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe report should be made immediately upon discovery to start the CMS incident response process. The IT Service Desk instructs the reporter to fill out an incident report using the Incident Report Template – which is then sent to the Incident Management Team (IMT). Incidents must be reported whether they are confirmed to have occurred or are only suspected to have occurred. The Helpdesk refers security and privacy incidents to IMT, which then coordinates efforts to analyze, contain, and eradicate the incident.\u003c/p\u003e\u003cp\u003eAll incidents involving CMS must be reported to HHS to ensure that HHS can provide accurate incident statistics for its OpDivs as per FISMA requirements. By integrating CMS’s incident ticketing system with HHS, CMS automatically notifies HHS of incidents. More details on the CMS Incident Response capability and reporting requirements for incidents other than breaches can be found in the Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAll breaches\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Incident Management Team (IMT) investigates reported security and privacy incidents to determine if they meet the definition of a breach. The team does not need confirmation of a breach to begin the breach response process – they should treat incidents as breaches as soon as the investigation reveals that PII, PHI, or FTI was jeopardized by an incident.\u003c/p\u003e\u003cp\u003eIf an incident reaches the status of a suspected breach, IMT conducts a risk assessment on the suspected breach using the Risk Assessment Checklist. Then they notify the CMS Breach Analysis Team (BAT) that a suspected breach has occurred and provide the BAT with the results of the risk assessment.\u003c/p\u003e\u003cp\u003eThe BAT convenes to review the risk assessment and determine the likelihood of sensitive data compromise according to the CMS Breach Analysis Team Handbook. The team assigns the breach a risk rating of Low, Moderate, or High, and advises the affected system’s Business Owner (BO) on whether CMS must notify the affected individuals. Should notification be necessary, the Senior Official for Privacy (SOP) at CMS works with the following people to develop a notification and mitigation plan:\u003c/p\u003e\u003cul\u003e\u003cli\u003eBusiness Owner of the CMS system affected by the breach\u003c/li\u003e\u003cli\u003eContracting Officer’s Representative (COR) for any affected contractors\u003c/li\u003e\u003cli\u003eIncident responders\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDepending on the nature and quantity of the sensitive data compromised by the breach, different reporting requirements apply:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIf a breach compromises \u003cstrong\u003ePHI/PII\u003c/strong\u003e, the HIPAA Breach Notification Rule applies.\u003c/li\u003e\u003cli\u003eIf a breach compromises \u003cstrong\u003eFTI\u003c/strong\u003e, the IRS requires that the U.S. Treasury Inspector General for Tax Administration (TIGTA) be notified.\u003c/li\u003e\u003cli\u003eIf a breach compromises any data that may impact U.S. national security or otherwise meets the definition of a \u003cstrong\u003emajor incident\u003c/strong\u003e, then Congress must be notified.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eLow risk scenarios\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSome privacy incidents are considered low risk and do not rise to the threshold of a breach. The Data Governance Board (DGB) has defined a set of criteria for such incidents in the Data Governance Board Guidelines. The IMT can close out these breaches automatically if they represent a sufficiently low risk to not require convening a full Breach Analysis Team.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreaches of PHI\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS’s administration of Medicare and Medicaid make the agency a covered entity under HIPAA and subject to the law’s reporting and notification requirements when PHI is breached. This includes reporting to the HHS Office of Civil Rights (OCR) of all breaches of Protected Health Information (PHI) for each calendar year –\u0026nbsp; including those that occur with a business associate.\u003c/p\u003e\u003cp\u003eAny compromise of PHI requires CMS to notify the affected individual(s) within 60 days. If a breach affects the PHI of more than 500 residents of a U.S. state or jurisdiction, CMS is also “required to provide notice to prominent media outlets serving the State or jurisdiction,” and notify OCR within 60 days. The Breach Analysis Team must work with the CMS Office of Communication’s Media Relations Group to complete this notification step.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreaches of FTI\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Internal Revenue Service (IRS) requires organizations handling FTI (federal tax returns and return information, including information derived from a return) to report any unauthorized access to or disclosure of FTI to the Treasury Inspector General for Tax Administration and the IRS Office of Safeguards within 24 hours of identifying the incident.\u003c/p\u003e\u003cp\u003eIf the Incident Management Team (IMT)\u0026nbsp; determines that there is a possibility that FTI has been compromised by an incident, they should immediately notify the CMS IRS Liaison to begin the process for reporting to the IRS and TIGTA. Breach response stakeholders should be aware that IRS may request additional data and updates from CMS as the incident response process continues.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMajor incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOMB requires agencies to report major incidents to Congress within seven days. The threshold for a major incident is a breach that affects more than 100,000 individuals. As an HHS OpDiv, CMS will report major incidents to the HHS Computer Security Incident Response Center (CSIRC) to assist HHS in making a report to Congress. CMS will also report major incidents to the CMS Office of Legislation to ensure that the Office can coordinate with HHS on any participation by CMS in the report.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eBreach response steps and deliverables\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBreach response activities at CMS require robust lines of communication and clearly defined deliverables between multiple organizations and components, including CMS groups, contractors and associates, and HHS entities.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIn general, the communication responsibilities of CMS, HHS, and entities are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCMS will be responsible for collecting data pertaining to the breach, developing a plan for notifying persons affected by the breach and mitigating any resulting harm, and reporting all breach response activities to HHS.\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eHHS will be responsible for coordinating between CMS and external federal agencies, as well as approving any notification and mitigation plans developed by CMS.\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eEntities operating on behalf of CMS (contractors and associates) are responsible for implementing notification and mitigation plans created by CMS and approved by HHS.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBreach response activities take place in tandem with incident response activities. Discovery of new data about a breach should be reported as soon as possible to HHS Computer Security Incident Response Center (CSIRC), to ensure that HHS can meet its own reporting requirements. (HHS CSIRC is the primary communication pathway between CMS and external organizations such as other federal agencies.)\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS maintains an incident ticketing system that automatically sends ticket updates to a mirrored ticket in the equivalent HHS CSIRC ticketing system. Incident responders must maintain this integration and ensure that tickets are promptly updated to communicate with HHS.\u003c/p\u003e\u003cp\u003eThe Incident Management Team, in keeping with its role during incident response, is the primary communication pathway between organizations within CMS and its contractors and associates. For more details on IMT’s role and process during incidents, see the CMS Risk Management Handbook Chapter 8: Incident Response.\u003c/p\u003e\u003cp\u003eBreach response activities are accomplished through four stages: reporting, risk assessment, breach analysis, and notification and mitigation.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eReporting\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe incident ticket submitted by the CMS IT Helpdesk is the first notice to CMS of a possible breach. The IT Helpdesk works with the individual reporting an incident to create an initial \u003cstrong\u003eincident report as a deliverable\u003c/strong\u003e to the Incident Management Team (IMT) and create a ticket to track the issue. The incident ticket is automatically mirrored in the equivalent HHS system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRisk assessment\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIMT works with the affected system’s officials and operators to investigate the incident. They assess the incident to determine if any categories of sensitive data may be compromised. If there is a possibility of compromise, the incident is considered a suspected breach. IMT conducts a risk assessment using the “Factors for Assessing the Risk of Harm to Potentially Affected Individuals” prescribed by OMB and defined in the CMS Risk Assessment for Breach Notification Determination form. Then they formally convene the Breach Analysis Team and provide the team with the\u003cstrong\u003e IMT Risk Assessment as a deliverable.\u003c/strong\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBreach analysis\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe Breach Analysis Team convenes to review the IMT Risk Assessment and categorizes the risk represented by the breach as low, moderate, or high, as described in the CMS Breach Analysis Team Handbook.\u003c/p\u003e\u003cp\u003eThe BAT consists of breach response stakeholders in leadership positions and security and privacy subject matter experts for the affected system, including the Business Owner, ISSOs, COR (if the affected system is a contractor system), Senior Official for Privacy, and the DCTSO Incident Commander.\u003c/p\u003e\u003cp\u003eThe BAT determines if the conditions of the breach warrant notifying the affected individuals. If so, the BAT drafts a \u003cstrong\u003eNotification and Mitigation Plan as a deliverable\u003c/strong\u003e to the HHS Privacy Incident Response Team (PIRT), using the HHS PIRT Response Plan Template. The Business Owner of the affected system has the final decision on whether notification and mitigation will go forward.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNotification and mitigation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eHHS PIRT reviews the Notification and Mitigation Plan. The PIRT may overrule the BAT on whether notification and mitigation are necessary or they may request changes to the plan. If the PIRT approves, the Business Owner of the affected system (and the COR if the affected system is a contractor system) are responsible for executing the approved plan.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTable of breach response deliverables\u003c/strong\u003e\u003c/h3\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eBreach Response Deliverable\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eResponsible\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eDelivered To\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eIncident Report Ticket\u003c/td\u003e\u003ctd\u003eCMS IT Helpdesk\u003c/td\u003e\u003ctd\u003eIncident Management Team (IMT). IMT continues to update the ticket with information about the breach as the response proceeds.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk Assessment\u003c/td\u003e\u003ctd\u003eIncident Management Team\u003c/td\u003e\u003ctd\u003eBreach Analysis Team (BAT)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eNotification and Mitigation Plan\u003c/td\u003e\u003ctd\u003eBreach Analysis Team\u003c/td\u003e\u003ctd\u003eHHS Privacy Incident Response Team (PIRT)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eBreach Notification to Affected Individuals\u003c/td\u003e\u003ctd\u003eSystem Business Owner / Contracting Officer’s Representative\u003c/td\u003e\u003ctd\u003eAffected individuals\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch2\u003e\u003cstrong\u003eBreach notification and mitigation\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe goal of breach response activities is to reduce the risk of harm to individuals that is created by a breach of sensitive data. If the Breach Analysis Team determines that a breach represents enough risk to individuals, they develop a Notification and Mitigation Plan.\u003c/p\u003e\u003cp\u003eThe CMS Senior Official for Privacy, in cooperation with the Business Owner of the affected system and with support from the full BAT, is responsible for developing the Notification and Mitigation Plan. CMS will receive approval to implement the plan from the HHS PIRT, using the HHS PIRT Response Plan Template as the formal deliverable. The Notification and Mitigation Plan must consider the nature and scope of the breach to determine if media organizations must be notified as per the HIPAA requirements.\u003c/p\u003e\u003cp\u003eOnce approved, the Notification and Mitigation Plan is implemented, with responsibility for implementation assigned to the Business Owner of the affected system (or the COR, if the affected system is a contractor system). If media notification is required, the BAT should coordinate with the CMS Media Relations Group (MRG).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNotification\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIf the Breach Analysis Team determines that a breach of PII represents a risk of harm to the affected individuals, then CMS must notify individuals whose PII is compromised in a breach. The team will develop a Notification and Mitigation Plan to describe the actions CMS will take to protect the affected individuals.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eIndividual notification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAs prescribed by the \u003ca href=\"/policy-guidance/breach-analysis-team-bat-handbook\"\u003eCMS Breach Analysis Team Handbook\u003c/a\u003e, the CMS Senior Official for Privacy works with the Business Owner of an affected CMS system to develop a notification letter describing the breach for individuals and submit it to HHS PIRT for approval.\u003c/p\u003e\u003cp\u003eOMB M-17-12 provides direction to federal agencies on what information should be included in breach notifications:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA brief description of what happened, including the date(s) of the breach and of its discovery\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA description of the types of sensitive data compromised by the breach (e.g., full name, Social Security Number, date of birth, home address, account number, and disability code), to the extent possible\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA statement of whether the information was encrypted or protected by other means, when it is determined that disclosing such information would be beneficial to potentially affected individuals and would not compromise the security of the information system\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eGuidance to potentially affected individuals on how they can mitigate their own risk of harm, the countermeasures undertaken, and any services provided to potentially affected individuals\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eAny steps being taken to investigate the breach, to mitigate losses, and to protect against a future breach\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eA description of how potentially affected individuals can learn more information about the breach, including a telephone number (preferably toll-free), email address, and postal address\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eHHS PIRT has oversight over CMS breach notification plans. After developing the notification letter and a plan to contact the affected individuals, the BAT should meet with HHS PIRT to gain approval to implement the plan. This meeting should also be attended by the Business Owner(s) of any affected CMS systems, the Contracting Officers of any CMS contractor partners who were involved in the breach, and the incident response personnel who investigated the breach to ensure that HHS PIRT can receive timely answers to any questions related to the breach.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eMedia notification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIn addition to individual notification, HIPAA requires CMS to notify local media outlets if a breach of PHI affects more than 500 individuals within a single locality.\u0026nbsp; The Breach Analysis Team should contact CMS Media Relations Group if a breach of PII/PHI affects more than 500 individuals to make certain that any plans to contact media outlets are included in the notification plan submitted to HHS PIRT for approval.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNotification through public CMS resources\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS must also consider that a widely publicized breach may cause members of the public to attempt to contact CMS with questions about the breach and inquire whether their own information was affected. As part of the notification plan, the Breach Analysis Team may determine that CMS should provide a public notification message on its public resources, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePosting on the cms.gov homepage to inform the public of the breach, with a link to further details\u0026nbsp;\u003cbr\u003e\u0026nbsp;\u003c/li\u003e\u003cli\u003eProviding CMS call centers with a message to play at the start of calls to inform callers how they can determine if they were affected by a breach\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eMitigation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAs part of its notification plan, the Breach Analysis Team must determine and document the actions that CMS will take to mitigate the risk of harm. If the breach puts the affected individuals at risk for identity theft, CMS will offer credit monitoring as prescribed by the CMS Breach Analysis Team Handbook.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eBudgeting considerations\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThere may be costs associated with implementing a notification and mitigation plan, such as providing a credit monitoring service free of charge to the affected individuals. If a contractor system is breached, the contractor should cover the costs of notification and mitigation. CMS contracts should establish this responsibility.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eRoles and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eBreach response stakeholders have direct or supporting roles and responsibilities during a breach. Some stakeholders in this group are associated with the FISMA system undergoing a breach and some are part of the CMS incident response capability. The breach response stakeholders have the following roles and responsibilities:\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCMS FISMA System Stakeholders\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eBusiness Owner (BO)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns decision to notify individuals affected by a breach and provide mitigation, with advisement from the BAT.\u003c/li\u003e\u003cli\u003eOwns decision to take major actions impacting system availability in response to a breach (such as shutting down a breached system).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003ePrimary Information System Security Officer (ISSO)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrimary system stakeholder in charge of providing data to IMT, BAT, and other breach response stakeholders about the affected system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOperations Teams (to include General Support System [GSS] support)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eTakes incident response actions on the system affected by the breach. May escalate decision to take major action impacting availability to the BO.\u003c/li\u003e\u003cli\u003eProvides system data to IMT, BAT and other breach response stakeholders at the direction of the ISSO.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCyber Risk Adviser (CRA)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides guidance to breach response stakeholders on risk and compliance for the affected system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eISPG Breach Response and Coordination\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eCMS CISO\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the breach response process.\u003c/li\u003e\u003cli\u003eIs kept apprised of all developments during breach response, analysis, notification, and mitigation.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCMS Senior Official for Privacy (SOP)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the Breach Analysis Team process.\u003c/li\u003e\u003cli\u003eOwns and oversees the Notification and Mitigation Plan, in cooperation with the system BO.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDCTSO Incident Coordinator\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eOwns the incident response process.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Cybersecurity Integration Center (CCIC)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eIncident Management Team (IMT)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrimary coordination entity for breach response. Works to provide leadership (BAT, senior officials) with data about the breach to make decisions.\u003c/li\u003e\u003cli\u003eConducts initial analysis and risk assessment of breaches to provide to the BAT.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eCMS Security Operations Center (SOC)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides technical support and security subject matter expertise to the BAT during a breach.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS Subject Matter Expert Support\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eCMS Office of Communications/Media Relations Group\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides notification to media outlets in the event of a breach affecting the PHI of more than 500 individuals.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOffice of General Counsel\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eProvides support to the BAT in the event of a major incident to help CMS prepare for congressional notification.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eBreach Analysis Team (BAT)\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003eOwns the risk decision (low/moderate/high) after IMT conducts a risk assessment.\u003c/li\u003e\u003cli\u003eWorks with the SOP and BO to advise on the Notification and Mitigation Plan.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eLaws and guidance\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eUse this list of applicable laws and guidance to learn more about the processes described in this handbook.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFederal laws\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.congress.gov/113/plaws/publ283/PLAW-113publ283.pdf\"\u003eFederal Information Security Modernization Act\u003c/a\u003e (FISMA) of 2014, Pub. L. 113-283, 128 Stat. 3073 (Dec. 18, 2014) (primarily codified at 44 U.S.C. chapter 35, subchapter 11).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.congress.gov/104/plaws/publ191/PLAW-104publ191.pdf\"\u003eHealth Insurance Portability and Accountability Act\u003c/a\u003e (HIPAA) of 1996, Pub. L. 104-191 (Aug. 21, 1996).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eExecutive orders, memoranda, and directives\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2017/m-17-12_0.pdf\"\u003eOMB Memorandum M-17-12\u003c/a\u003e, Preparing for and Responding to a Breach of Personally Identifiable Information (January 3, 2017).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.whitehouse.gov/wp-content/uploads/2019/11/M-20-04.pdf\"\u003eOMB Memorandum M-20-04\u003c/a\u003e, Fiscal Year 2019-2020 Guidance on Federal Information Security and Privacy Management Requirements (November 19, 2019).\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf\"\u003eOMB Circular A-130, Managing Information as a Strategic Resource\u003c/a\u003e (July 28, 2016).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/the-press-office/2016/07/26/annex-presidential-policy-directive-united-states-cyber-incident\"\u003ePPD-41, Annex for Presidential Policy Directive\u003c/a\u003e – United States Cyber Incident Coordination (July 26, 2016).\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/memoranda/2016/m-16-14.pdf\"\u003eOMB Memorandum M-16-14, Category Management Policy 16-2\u003c/a\u003e: Providing Comprehensive Identity Protection Services, Identity Monitoring, and Data Breach Response (July 1, 2016).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eCMS / HHS policy and procedures\u003c/strong\u003e\u003c/h3\u003e\u003cul\u003e\u003cli\u003eCMS Risk Management Handbook (RMH) Chapter 8: Incident Response\u003c/li\u003e\u003cli\u003eCMS Breach Analysis Team Handbook\u003c/li\u003e\u003cli\u003eData Governance Guidelines\u003c/li\u003e\u003cli\u003eHHS PIRT Response Plan Template\u003c/li\u003e\u003cli\u003eCMS Risk Assessment for Breach Notification Determination\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAdditional guidance\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003eDepartment of Commerce / National Institute of Standards and Technology (NIST)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eNIST Special Publication 800-34 (Revision 1), \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf\"\u003eContingency Planning Guide for Federal Information Systems and Organizations\u003c/a\u003e (Apr. 2013).\u0026nbsp;\u003c/li\u003e\u003cli\u003eNIST Special Publication 800-61 (Revision 2), \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf\"\u003eComputer Security Incident Handling Guide\u003c/a\u003e (Aug. 2012).\u0026nbsp;\u003c/li\u003e\u003cli\u003eNIST Special Publication 800-122, \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf\"\u003eGuide to Protecting the Confidentiality of PII\u003c/a\u003e (Apr. 2010).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDepartment of Homeland Security (DHS) / United States Computer Emergency Readiness Team (US-CERT)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.cisa.gov/uscert/incident-notification-guidelines\"\u003eUS-CERT Federal Incident Notification Guidelines\u003c/a\u003e\u003c/li\u003e\u003cli\u003eNational Cybersecurity and Communications Integration Center (NCCIC) \u003ca href=\"https://www.cisa.gov/uscert/CISA-National-Cyber-Incident-Scoring-System\"\u003eCyber Incident Scoring System\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eGeneral Services Administration (GSA)\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.gsa.gov/buy-through-us/products-services/professional-services/buy-services/identity-protection-services-ips\"\u003eIdentity Protection Services (IPS) Multiple Award Blanket Purchase Agreement (BPA)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"210:{\"value\":\"$211\",\"format\":\"body_text\",\"processed\":\"$212\",\"summary\":\"\"}\n215:[]\n214:{\"uri\":\"entity:node/696\",\"title\":\"Breach Response \",\"options\":\"$215\",\"url\":\"/learn/breach-response\"}\n217:[]\n216:{\"uri\":\"entity:node/701\",\"title\":\"CMS Breach Analysis Team (BAT) Handbook \",\"options\":\"$217\",\"url\":\"/policy-guidance/cms-breach-analysis-team-bat-handbook\"}\n213:[\"$214\",\"$216\"]\n218:{\"value\":\"Procedures for handling a breach of sensitive data at CMS, including roles, responsibilities, and reporting requirements\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eProcedures for handling a breach of sensitive data at CMS, including roles, responsibilities, and reporting requirements\u003c/p\u003e\\n\"}\n20e:{\"drupal_internal__nid\":621,\"drupal_internal__vid\":4913,\"langcode\":\"en\",\"revision_timestamp\":\"2023-08-23T18:12:45+00:00\",\"status\":true,\"title\":\"CMS Breach Response Handbook\",\"created\":\"2022-12-30T21:49:21+00:00\",\"changed\":\"2023-08-23T18:12:45+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":null,\"moderation_state\":\"published\",\"path\":\"$20f\",\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":\"$210\",\"field_contact_email\":\"IMT@cms.hhs.gov\",\"field_contact_name\":\"Incident Management Team\",\"field_last_reviewed\":\"2022-11-07\",\"field_related_resources\":\"$213\",\"field_short_description\":\"$218\"}\n21c:{\"drupal_internal__target_id\":\"library\"}\n21b:{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":\"$21c\"}\n21e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/node_type?resourceVersion=id%3A4913\"}\n21f:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/node_type?resourceVersion=id%3A4913\"}\n21d:{\"related\":\"$21e\",\"self\":\"$21f\"}\n21a:{\"data\":\"$21b\",\"links\":\"$21d\"}\n222:{\"drupal_internal__target_id\":36}\n221:{\"type\":\"user--user\",\"id\":\"663db243-0ec9-4d3f-9589-5a0ed308fbbc\",\"meta\":\"$222\"}\n224:{\"href\":\"https://c"])</script><script>self.__next_f.push([1,"ybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/revision_uid?resourceVersion=id%3A4913\"}\n225:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/revision_uid?resourceVersion=id%3A4913\"}\n223:{\"related\":\"$224\",\"self\":\"$225\"}\n220:{\"data\":\"$221\",\"links\":\"$223\"}\n228:{\"drupal_internal__target_id\":6}\n227:{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":\"$228\"}\n22a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/uid?resourceVersion=id%3A4913\"}\n22b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/uid?resourceVersion=id%3A4913\"}\n229:{\"related\":\"$22a\",\"self\":\"$22b\"}\n226:{\"data\":\"$227\",\"links\":\"$229\"}\n22e:{\"drupal_internal__target_id\":91}\n22d:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":\"$22e\"}\n230:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/field_resource_type?resourceVersion=id%3A4913\"}\n231:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/field_resource_type?resourceVersion=id%3A4913\"}\n22f:{\"related\":\"$230\",\"self\":\"$231\"}\n22c:{\"data\":\"$22d\",\"links\":\"$22f\"}\n235:{\"drupal_internal__target_id\":66}\n234:{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":\"$235\"}\n237:{\"drupal_internal__target_id\":61}\n236:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":\"$237\"}\n239:{\"drupal_internal__target_id\":76}\n238:{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":\"$239\"}\n233:[\"$234\",\"$236\",\"$238\"]\n23b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/field_roles?resourceVersion=id%3A4913\"}\n23c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/field_roles?resourceVersion=id%3A4913\"}\n23a:{\"related\":\""])</script><script>self.__next_f.push([1,"$23b\",\"self\":\"$23c\"}\n232:{\"data\":\"$233\",\"links\":\"$23a\"}\n240:{\"drupal_internal__target_id\":31}\n23f:{\"type\":\"taxonomy_term--topics\",\"id\":\"d5e2c0ee-04cb-493b-9338-c97adf0e8adf\",\"meta\":\"$240\"}\n23e:[\"$23f\"]\n242:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/field_topics?resourceVersion=id%3A4913\"}\n243:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/field_topics?resourceVersion=id%3A4913\"}\n241:{\"related\":\"$242\",\"self\":\"$243\"}\n23d:{\"data\":\"$23e\",\"links\":\"$241\"}\n219:{\"node_type\":\"$21a\",\"revision_uid\":\"$220\",\"uid\":\"$226\",\"field_resource_type\":\"$22c\",\"field_roles\":\"$232\",\"field_topics\":\"$23d\"}\n20b:{\"type\":\"node--library\",\"id\":\"4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e\",\"links\":\"$20c\",\"attributes\":\"$20e\",\"relationships\":\"$219\"}\n246:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a?resourceVersion=id%3A5866\"}\n245:{\"self\":\"$246\"}\n248:{\"alias\":\"/policy-guidance/cms-plan-action-and-milestones-poam-handbook\",\"pid\":391,\"langcode\":\"en\"}\n24a:T9cb3,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is a POA\u0026amp;M?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Plan of Action and Milestones (POA\u0026amp;M) is a corrective action plan that tracks system weakness and allows System Owners and ISSOs to create a plan to resolve the identified weaknesses over time. A POA\u0026amp;M provides details about the personnel, technology, and funding required to accomplish the elements of the plan, milestones for correcting the weaknesses, and scheduled completion dates for the milestones.\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePOA\u0026amp;M process overview\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe POA\u0026amp;M process begins when a weakness is identified in a CMS FISMA system. Working together, the System/Business Owner and the Authorizing Official (AO) are responsible for mitigating the risk posed by the weakness, with support from the Information System Security Officer (ISSO) and Cyber Risk Advisor (CRA). The steps to the POA\u0026amp;M process are outlined below, and will be described in greater detail throughout the remainder of this guide:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIdentify weaknesses\u003c/li\u003e\u003cli\u003eDevelop a Corrective Action Plan (CAP)\u003c/li\u003e\u003cli\u003eDetermine resource and funding availability\u003c/li\u003e\u003cli\u003eAssign a completion date\u003c/li\u003e\u003cli\u003eExecute the Corrective Action Plan (CAP)\u003c/li\u003e\u003cli\u003eVerify weakness completion\u003c/li\u003e\u003cli\u003eAccept risk when applicable\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eIdentifying weaknesses\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe term “weakness” represents any information security or privacy vulnerability that could be exploited as a result of a specific control deficiency. Weaknesses can compromise a system’s confidentiality, integrity, or availability. All weaknesses that represent risk to the security or privacy of a system must be corrected and the required mitigation efforts captured in a POA\u0026amp;M.\u0026nbsp;For the purpose of this document, the term “weakness” as defined in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53, rev. 5 \u003c/a\u003ewill be synonymous with the terms finding and vulnerability. These terms are defined below:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eFinding\u003c/strong\u003e – During an assessment or audit, the security and privacy controls of a system are tested, or exercised. A system either satisfies the requirements or a control or does not satisfy it.\u0026nbsp; Findings are the result of the assessment or audit. Findings that do not satisfy a control must be addressed with a POA\u0026amp;M.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eVulnerability\u003c/strong\u003e – A vulnerability is a weakness in a system, a system’s security procedures, its internal controls, or its implementation that could be exploited or triggered by a threat source.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFinding weaknesses\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWeaknesses may be found during an internal or external audit, review, or through Continuous Diagnostics and Mitigation (CDM) efforts. There are a number of specific sources that help system teams identify weaknesses:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eHHS OIG Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eGovernment Accountability Office (GAO) Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eChief Financial Officer (CFO) Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eOMB A-123 Internal Control Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eAnnual Assessments\u003c/li\u003e\u003cli\u003eFISMA Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e or Security Control Assessments (SCA)\u0026nbsp;\u003c/li\u003e\u003cli\u003eMedicare Prescription Drug, Improvement, and Modernization Act of 2003 (MMA) Section 912 Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eInternal Revenue Service (IRS) Safeguard Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eDepartment of Homeland Security (DHS) Risk Vulnerability Assessments (RVA)\u0026nbsp;\u003c/li\u003e\u003cli\u003eDHS Cyber Hygiene\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/penetration-testing\"\u003ePenetration Testing\u0026nbsp;\u003c/a\u003e\u003c/li\u003e\u003cli\u003eVulnerability Scanning\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDuring these assessments, reviews, and audits, weaknesses can be found either proactively or reactively.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProactive - \u003c/strong\u003eProactive weakness identification occurs during regular system reviews conducted by CMS.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eReactive - \u003c/strong\u003eReactive weakness determination indicates that the weakness was identified during an audit or external review, like a penetration test.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWeaknesses are always documented by the source that identified them, and it’s important to indicate the identification source as you create your POA\u0026amp;M.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeakness severity levels\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere are three severity levels for all weaknesses discovered during assessments, audits, and tests. The risk the weakness poses to the agency’s overall security and privacy posture determines a weakness’ severity level . There are three levels of severity as defined by OMB: significant deficiency, reportable condition, and weakness.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWeakness severity levels\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eSignificant deficiency\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA weakness is considered a \u003cstrong\u003esignificant deficiency\u003c/strong\u003e if it drastically restricts the capability of the agency to carry out its mission or if it compromises the security or privacy of its information, information systems, personnel, or other resources, operations, or assets.\u0026nbsp;\u003c/p\u003e\u003cp\u003eSenior management must be notified and immediate or near immediate corrective action must be taken.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eReportable Condition\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA \u003cstrong\u003ereportable condition\u003c/strong\u003e is a weakness that affects the efficiency and effectiveness of agency operations.\u0026nbsp;\u003c/p\u003e\u003cp\u003eDue to its lower associated risk, corrective actions for a reportable condition may be scheduled over a longer period of time. The control auditor or assessor will make the determination that a weakness is a reportable condition.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWeakness\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eAll other weaknesses that do not rise to the level of a significant deficiency or reportable condition must be categorized as a weakness.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThey must be mitigated in a timely and efficient manner, as resources permit.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe weakness severity level can be obtained from the source or the audit report. Most findings will generally be categorized as a “weakness”. In the event that a weakness is designated as a “significant deficiency”, then contact the \u003ca href=\"mailto:ciso@cms.hhs.gov\"\u003eCISO mailbox \u003c/a\u003efor further guidance.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeakness risk level\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final\"\u003eNIST SP 800-30 \u003c/a\u003econtains the definitions and the practical guidance necessary for assessing and mitigating identified risks to IT systems. Risk level is dependent on multiple factors, such as \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFederal Information Processing Standard (FIPS) 199 \u003c/a\u003ecategory, operating environment, compensating controls, nature of the vulnerability, and impact if a system is compromised.\u003c/p\u003e\u003cp\u003eRisk can be evaluated either qualitatively or quantitatively and is typically expressed in its simplified form as:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRISK = THREAT x IMPACT x LIKELIHOOD\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe result of the analysis of the risk(s) from following the NIST SP 800-30 guide will recommend the overall risk level assigned to FISMA system of record.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRoot Cause Analysis (RCA)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll weaknesses must be examined to determine their root cause prior to documentation in the\u003c/p\u003e\u003cp\u003ePOA\u0026amp;M. \u003cstrong\u003eRoot Cause Analysis (RCA)\u003c/strong\u003e is an important and effective methodology used to correct information security or privacy weaknesses by eliminating the underlying cause. Various factors are reviewed to determine if they are the underlying cause of the weakness. Proper evaluation ensures the cause, not the symptom, is treated and prevents resources from being expended unnecessarily on addressing the same weakness.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrioritizing weaknesses\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS takes a risk management approach to ensure that critical and high-impact weaknesses\u0026nbsp;\u003c/p\u003e\u003cp\u003etake precedence over lower security weaknesses. The following chart will help CMS System/Business Owners and ISSOs prioritize weaknesses on an ongoing basis to ensure that high-priority weaknesses receive the funding and the resources necessary to remediate or mitigate the most significant risks.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePrioritization factor\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDescription\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk level/severity\u003c/td\u003e\u003ctd\u003e\u003cp\u003eWeaknesses on a High or Moderate system or weaknesses that contribute to a material weakness, significant deficiency or reportable condition will normally require more immediate resolution.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis prioritization factor must consider the following elements:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eSensitivity and criticality of information on the system, such as personally identifiable information (PII).\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe estimated likelihood of the weakness occurring and/or being exploited.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe cost of a potential occurrence or exploitation in terms of dollars, resources,, and/or reputation\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAnalysis\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe weakness must be analyzed to determine if there are any other processes or system relationships that it may affect.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDoes the weakness fall within the system authorization boundary?\u0026nbsp;\u003c/li\u003e\u003cli\u003eIs it a potential program weakness?\u0026nbsp;\u003c/li\u003e\u003cli\u003eIs the weakness a systemic issue (across the enterprise) or is it an isolated event?\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSystemic issues represent much greater risk and may be a higher priority.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSource\u003c/td\u003e\u003ctd\u003eWhat is the source of the weakness? For example, if the weakness resulted from an audit and is considered a significant deficiency, then greater attention should be focused on this weakness.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVisibility\u003c/td\u003e\u003ctd\u003eHas the weakness drawn a high level of visibility external to the system or program? In some cases, a lower level weakness is a higher priority due to visibility. There are times when senior management or outside organizations focus on a specific weakness. Such weaknesses may take priority.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eRegardless of how the weakness is found and how severe it is,\u0026nbsp;it’s critical that system teams work together to create a Corrective Action Plan (CAP) to address it.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDevelop a Corrective Action Plan (CAP)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAfter weaknesses have been identified and the root cause has been determined, a \u003cstrong\u003eCorrective Action Plan (CAP)\u003c/strong\u003e must be developed. The CAP identifies:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe specific tasks, or “milestones”, that need to be accomplished to reduce or eliminate weakness\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe resources required to accomplish the plan\u003c/li\u003e\u003cli\u003eA timeline for correcting the weakness including a completion date\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe milestones in the CAP must provide specific, action-oriented descriptions of the tasks/steps that the stakeholder will take to mitigate the weakness. When creating your milestones, be sure that they are:\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSpecific\u003c/strong\u003e – target a specific area for improvement\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eMeasurable\u003c/strong\u003e – quantify or at least suggest an indicator of progress\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eAssignable\u003c/strong\u003e – specify who will do it\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRealistic\u003c/strong\u003e – state what results can realistically be achieved, given available resources\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eTime-related\u003c/strong\u003e – specify when the result(s) can be achieved.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe number of milestones written per weakness must directly correspond to the number of steps or corrective actions necessary to fully address and resolve the weakness. Each weakness must have at least one corresponding milestone with an estimated completion date and resource requirements to remediate the weakness. The chart below provides samples of compliant and non-compliant milestones that system teams can use when writing their CAP.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eExamples of appropriate milestones\u0026nbsp;\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePOA\u0026amp;M description\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eExample\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eMilestones with completion dates\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP)\u003c/td\u003e\u003ctd\u003eInappropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eEnsure vulnerability scanning covers the entire environment; (11/15/2018)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP)\u003c/td\u003e\u003ctd\u003eAppropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eSchedule a review of the environment inventory; (11/15/2018)\u003c/li\u003e\u003cli\u003eUpdate the SSPP and the vulnerability scanner to reflect the updated inventory; (1/31/2019)\u003c/li\u003e\u003cli\u003eConduct a vulnerability scan to check that the entire inventory is included; (2/15/2019)\u003c/li\u003e\u003cli\u003eImplement an ongoing process to evaluate and update the inventory, the SSPP, and the vulnerability scans on a regular basis; (3/15/2019)\u003c/li\u003e\u003cli\u003ePerform a vulnerability scan and cross check the output with the updated inventory list to verify that the entire environment is included; (4/15/2019)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit logs are not periodically reviewed\u003c/td\u003e\u003ctd\u003eInappropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eEnsure that audit logs are periodically reviewed; (12/15/2018)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit logs are not periodically reviewed\u003c/td\u003e\u003ctd\u003eAppropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eReview policy to ensure that audit log review is required; (12/15/2018)\u003c/li\u003e\u003cli\u003eIdentify the SO; (12/16/2018)\u003c/li\u003e\u003cli\u003eEstablish communication and training to convey the requirement of audit log review; (2/28/2019)\u003c/li\u003e\u003cli\u003eSchedule a follow-up review with the SO to ensure that audit log review is taking place. (3/31/2019)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe CAP should be a collaborative effort with stakeholders including the CISO, System/Business Owners, System Developers and Maintainers, ISSOs, and others as needed. These stakeholders ensure that the CAP is created, executed, monitored, and worked to closure or risk-based acceptance.\u003c/p\u003e\u003cp\u003eOMB provides a standard POA\u0026amp;M format which is utilized at CMS. This structure improves the stakeholders’ ability to easily locate information and organize details for analysis. The CAP format includes a location for the identified program weakness, any associated milestones, and the necessary resources required.\u0026nbsp;\u003c/p\u003e\u003cp\u003eOnce the CAP is documented, the plan must be entered into \u003ca href=\"https://cfacts.cms.gov/\"\u003eCFACTS\u003c/a\u003e in the form of a series of milestone records. The status of the POA\u0026amp;M will automatically be moved from “draft” to “ongoing” 30 days after the weakness creation date. Once a milestone has been accepted/approved and closed, the record must be retained for one year.\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDetermine resource and funding availability\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eMaking funding decisions is often a collaborative exercise that involves multiple system personnel and stakeholders. Examples of questions to ask to determine if your team has the resources to appropriately respond to a weakness are:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eIs one team or person enough or will the participation of a larger team be needed?\u0026nbsp;\u003c/li\u003e\u003cli\u003eCan the task be accomplished within a week or will it take several months?\u0026nbsp;\u003c/li\u003e\u003cli\u003eHow serious is the weakness?\u0026nbsp;\u003c/li\u003e\u003cli\u003eWhat is this weakness’ risk level?\u0026nbsp;\u003c/li\u003e\u003cli\u003eHow complex is the CAP?\u0026nbsp;\u003c/li\u003e\u003cli\u003eDo we need to purchase equipment?\u003c/li\u003e\u003cli\u003eCan the weakness be addressed with existing funding or will we require new allocation from an existing budget source?\u0026nbsp;\u003c/li\u003e\u003cli\u003eWill my addressing this milestone require changes to existing policy or code?\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe System/Business Owner, ISSOs, and other stakeholders must ensure that adequate resources are allocated to mitigate or remediate weaknesses. They must also work together to determine the funding stream required to address the weakness, and any full-time equivalent (FTE) resources required to remediate or mitigate each weakness on the POA\u0026amp;M. The resources required for weakness remediation must fall into one of the following three categories:\u003c/p\u003e\u003col\u003e\u003cli\u003eUsing current resources allocated for the security and/or management of a program or system to complete remediation activities\u003c/li\u003e\u003cli\u003eReallocating existing funds that are appropriated and available for the remediation, or redirecting existing personnel\u003c/li\u003e\u003cli\u003eRequesting additional funding or personnel\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eDuplicate or similar weaknesses shall be documented in one POA\u0026amp;M, existing or new, to avoid inconsistencies. If a related POA\u0026amp;M already exists, the additional weakness shall be noted in the comment field.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAssign a completion date\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSystem/Business Owners, ISSOs, and other stakeholders must determine the scheduled completion date for each weakness using the criteria established by the remediation and mitigation timeline, the risk level, and the severity level. The milestone(s) completion date must not exceed the scheduled completion date assigned to the weakness.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIt is also a good practice to first determine the milestones with completion dates, as this will help determine a more accurate overall scheduled completion date for the weakness. The weakness schedule completion date is a calculated date. It is determined by the identified date and the risk level. The scheduled completion date established at the creation of the weakness must not be modified after the weakness is reported to OMB. POA\u0026amp;Ms become reportable once the status changes from “Draft” to “Ongoing” in CFACTS.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf a weakness is not remediated within the scheduled completion date, a new estimated completion date must be determined and documented in the Changes to Milestones and Comment fields in the POA\u0026amp;M in CFACTS.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNOTE: In use cases where a responsive and timely POA\u0026amp;M cannot be developed, the ISSO can choose to consider the Risk Based Decision (RBD) process to request the Authorizing Official (AO) to consider a risk acceptance until such time the vulnerability can be remediated.\u003c/em\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eExecute the Corrective Action Plan (CAP)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA designated Point of Contact (POC), responsible for ensuring proper execution of the CAP, must be identified for each weakness and its milestones. Individual(s) responsible for the execution of the CAP vary widely depending on the organization, system, milestones, and weakness.\u003c/p\u003e\u003cp\u003eThis POC resource will be key to identifying an “owner” of the milestone and ensuring the milestone is worked to the eventual remediation of the weakness or acceptable mitigation of the weakness. Once the planning of the necessary corrective action is complete and adequate resources have been made available, remediation or mitigation activities will proceed in accordance with the plan.\u003c/p\u003e\u003cp\u003eIf the completion of a milestone extends past its original estimated completion date, an update to the milestone and the completion date of the milestone must be captured in the “Changes to Milestone” field of CFACTS. If the scheduled completion date has passed before the weakness is remediated or mitigated, the weakness must default to “Delayed” status and a justification with a new estimated completion date must be documented in the “Comment” field and the “Changes to Milestone” field of the relevant weakness in CFACTS.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eVerify weakness completion\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS requires that all information in the POA\u0026amp;M be updated at least quarterly, ensuring accuracy for efficient tracking and reporting. As part of the review process, the ISSO will:\u003c/p\u003e\u003cul\u003e\u003cli\u003eValidate that the weakness is properly identified and prioritized\u003c/li\u003e\u003cli\u003eEnsure that appropriate resources have been made available to resolve the weakness\u003c/li\u003e\u003cli\u003eEnsure that the schedule for resolving the weakness is both appropriate and achievable\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eAccept risk when applicable\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA POA\u0026amp;M is a plan to resolve unacceptable risks. In rare cases, the Business Owner can present a case for accepting the risk to the AO or CIO, who may make the decision to accept the risk at their discretion. This is part of the Risk Based Decision (RBD) process. After approval, RBDs shall be reviewed at least annually to ensure the risk remains acceptable and updated as events occur and information changes. RBDs are managed in CFACTS under the \"RBD\" tab.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eClosing a POA\u0026amp;M\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePOA\u0026amp;Ms designated as Low and Moderate are closed by the ISSO and spot audited by a CRA.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms designed as Critical and High are closed by the CRA.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms generated from audits should be reviewed by the auditor prior to closure.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms resulting from a Penetration Test (PenTest) are closed by the PenTest team after the re-test has been performed.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eReports\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eReporting is a critical component of POA\u0026amp;M management, and CMS reports its remediation efforts on a monthly basis. The information in the POA\u0026amp;M must be maintained continuously to communicate overall progress. CMS must submit POA\u0026amp;M updates at least once a month (by the 3rd business day of each month) to HHS to demonstrate the status of POA\u0026amp;M mitigation or remediation activities.\u003c/p\u003e\u003cp\u003eCMS must submit the following information in accordance with the Department POA\u0026amp;M reporting requirements:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAll POA\u0026amp;Ms associated with a program, system and/or component that are within an authorization boundary. POA\u0026amp;Ms must be tied to the individual system and/or component and not the authorization boundary.\u003c/li\u003e\u003cli\u003eAn explanation associated with each delayed POA\u0026amp;M and a revised estimated completion date.\u003c/li\u003e\u003cli\u003eCompleted POA\u0026amp;Ms for up to one year from the date of completion.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eWeakness remediation and mitigation timeline\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAfter positive identification of scan findings or approval of security assessment and/or audit report, all findings/weaknesses shall be documented in a POA\u0026amp;M, reported to HHS, and remediated/mitigated within the following remediation timelines.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eCritical within 15 days\u003c/li\u003e\u003cli\u003e\u0026nbsp;High within 30 days\u003c/li\u003e\u003cli\u003eModerate within 90 days\u003c/li\u003e\u003cli\u003eLow within 365 days\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBusiness Owners, ISSOs, and/or other POA\u0026amp;M stakeholders must work together to determine the scheduled completion date for each POA\u0026amp;M within the specified remediation timelines. These timelines are based on the date the weakness is identified, not the date the POA\u0026amp;M is created. Stakeholders should complete and submit their CAAT templates in a timely manner to allow for the maximum time to complete the remediation/mitigation.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf it is determined that additional time is needed to remediate or mitigate a weakness, the justification with a modified estimated completion date shall be documented in the POA\u0026amp;M in the Changes to Milestones and Comment fields in CFACTS. If weaknesses are not remediated within the scheduled completion date, the status shall change to “Delayed”.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeaknesses discovered during a government audit\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWeaknesses identified during a government audit (i.e., Inspector General or GAO audit) shall be documented in the POA\u0026amp;M after the audit draft report is produced, regardless of CMS acceptance of the identified weakness(es). Disagreements on findings that cannot be resolved between CMS and the auditing office shall be elevated to the Department for resolution. Systems must review and update POA\u0026amp;Ms at least quarterly. In addition, compensating controls must be in place and documented until weaknesses are remediated or mitigated to an acceptable level of risk.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eCFACTS\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eStakeholders must use\u0026nbsp;\u003ca href=\"https://cfacts.cms.gov/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eCFACTS\u003c/a\u003e, the CMS GRC tool, to identify, track, and manage all system weaknesses and associated POA\u0026amp;Ms to closure for CMS information systems. Users who need access to CFACTS may request an account and appropriate privileges through the Enterprise User Administration (EUA). The job code is \u003cstrong\u003eCFACTS_User_P\u003c/strong\u003e. Once the job code is assigned, the user must email the CISO mailbox at \u003ca href=\"mailto:ciso@cms.hhs.gov\"\u003eciso@cms.hhs.gov\u003c/a\u003e to notify the CISO of the user’s role (ISSO, System Developer, or System/Business Owner).\u003c/p\u003e\u003cp\u003eThe \u003cstrong\u003eCFACTS User Manual\u003c/strong\u003e provides detailed instructions for processing POA\u0026amp;M actions in the CFACTS tracking system. The User Manual can be accessed under the \u003cstrong\u003eCFACTS Documents\u003c/strong\u003e section on the \u003cstrong\u003eCFACTS Artifacts\u003c/strong\u003e page which can be accessed by clicking on the CFACTS Artifacts icon on the welcome page.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePOA\u0026amp;M Glossary\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe following glossary will help system teams understand the language of the POA\u0026amp;M process.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eTerm\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDefinition\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAnnual Assessment\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe process of validating the effective implementation of security and privacy controls in the information system and its environment of operation within every three hundred sixty-five (365) days in accordance with the CMS Information Security (IS) Acceptable Risk Safeguards (ARS) Including CMS Minimum Security Requirements (CMSR) Standard, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit\u003c/td\u003e\u003ctd\u003eAn independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCapital Planning and Investment Control\u003c/td\u003e\u003ctd\u003eA decision-making process for ensuring that investments integrate strategic planning, budgeting, procurement, and the management of or in support of Agency missions and business needs. [OMB Circular No. A-11]. The term comes from the Clinger-Cohen Act of 1996; while originally focused on IT, it now applies also to non-IT investments.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCommon Control\u003c/td\u003e\u003ctd\u003eA security or privacy control that is inherited by one or more organizational information systems. See Security Control Inheritance.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompleted\u003c/td\u003e\u003ctd\u003eA status assigned when all corrective actions have been completed or closed for a weakness and the weakness has been verified as successfully mitigated. Documentation is required to demonstrate the weakness has been adequately resolved. When assigning the status of ‘Completed’, the date of completion must also be included.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompletion date\u003c/td\u003e\u003ctd\u003eThe action date when all weaknesses have been fully resolved and the corrective action plan has been tested.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eControl activities\u003c/td\u003e\u003ctd\u003eThe policies and procedures that help ensure that management directives are carried out. They help ensure that necessary actions are taken to address risks to achievement of the entity’s objectives. Control activities, whether automated or manual, help achieve control objectives and are applied at various organizational and functional levels.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eControl deficiency\u003c/td\u003e\u003ctd\u003eA deficiency that exists when the design or operation of a control does not allow management or employees to, in the normal course of performing their assigned functions, prevent or detect breaches of confidentiality, integrity, or availability on a timely basis. (See also design deficiency or operations deficiency)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCorrective Action Plan (CAP)\u003c/td\u003e\u003ctd\u003eThe plan management formulates to document the procedures and milestones identified to correct control deficiencies.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCriteria\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA context for evaluating evidence and understanding the findings, conclusions, and recommendations included in the report. Criteria represent the laws, regulations, contracts, grant agreements, standards, specific requirements, measures, expected performance, defined business practices, and benchmarks against which performance is compared or evaluated.\u003c/p\u003e\u003cp\u003eCriteria identify the required or desired state or expectation with respect to the program or operation.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDelayed\u003c/td\u003e\u003ctd\u003eA status assigned when a weakness continues to be mitigated after the original scheduled completion date has passed. When assigning the status of ‘Delayed,’ an explanation must be provided in the milestone as to why the delay is occurring, as well as the revised completion date.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDesign deficiency\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA deficiency that exists when a control necessary to meet the control objective is missing or an existing control is not properly designed, so that even if the control operates as designed the control objective is not always met.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDraft\u003c/td\u003e\u003ctd\u003eA status that indicates that a weakness requires review and approval prior to “official” entry in the POA\u0026amp;M. Types of review that may take place while a weakness is in draft status would be: reviewing to determine if the weakness already exists and would be a duplicate; reviewing to determine if the organization will accept the risk, or apply for a waiver; etc.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eEvidence\u003c/td\u003e\u003ctd\u003eAny information used by the auditor, tester, or evaluator, to determine whether the information being audited, evaluated, or assessed is stated in accordance with the established criteria.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFISMA Audit\u003c/td\u003e\u003ctd\u003eA FISMA assessment designed to determine areas of compliance and areas requiring remediation to become FISMA compliant.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFederal Information Security Modernization Act (FISMA)\u003c/td\u003e\u003ctd\u003eRequires agencies to integrate information technology (IT) security into their capital planning and enterprise architecture processes at the agency, conduct annual IT security reviews of all programs and systems, and report the results of those reviews to the OMB. [NIST SP 800-65]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFindings\u003c/td\u003e\u003ctd\u003eConclusions based on an evaluation of sufficient, appropriate evidence against criteria.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInformation Security Risk\u003c/td\u003e\u003ctd\u003eThe risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and /or information systems.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePrimary Information System Security Officer (ISSO)\u003c/td\u003e\u003ctd\u003eIndividual with assigned responsibility for maintaining the appropriate operational security and privacy posture for an information system or program.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInitial audit findings\u003c/td\u003e\u003ctd\u003eAny type of audit conducted on a financial system or a non-financial system.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInternal control\u003c/td\u003e\u003ctd\u003eAn integral component of an organization’s management systems that provides reasonable assurance that the following objectives are being achieved: effectiveness and efficiency of operations, reliability of financial reporting, or compliance with applicable laws and regulations.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eManagement controls\u003c/td\u003e\u003ctd\u003eThe security or privacy controls (i.e., safeguards or countermeasures) for an information system that focus on the management of risk and the management of information system security and privacy.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eMaterial weakness\u003c/td\u003e\u003ctd\u003eMaterial weaknesses includes reportable conditions in which the Secretary or Component Head determines to be significant enough to report outside of the Department. Material weakness in internal control over financial reporting is a reportable condition, or combination of reportable conditions, that results in more than a remote likelihood that a material misstatement of the financial statements, or other significant financial reports, will not be prevented or detected.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eMetrics\u0026nbsp;\u003c/td\u003e\u003ctd\u003eTools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance-related data.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eNon-conformance\u0026nbsp;\u003c/td\u003e\u003ctd\u003eInstances in which financial management systems do not substantially conform to financial systems requirements. Financial management systems include both financial and financially-related (or mixed) systems.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOngoing\u003c/td\u003e\u003ctd\u003eA status assigned when a weakness is in the process of being mitigated and has not yet exceeded the original scheduled completion date.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOperational controls\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe security or privacy controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by people (as opposed to systems).\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOperations deficiency\u003c/td\u003e\u003ctd\u003eA deficiency that exists when a properly designed control does not operate as designed or when the person performing the control is not qualified or properly skilled to perform the control effectively.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePending verification\u003c/td\u003e\u003ctd\u003eA status that indicates that all milestones/corrective actions have been completed but require review and sign-off to ensure effective resolution.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePlan of Action and Milestones (POA\u0026amp;M)\u003c/td\u003e\u003ctd\u003eA FISMA mandated corrective action plan to identify and resolve information security and privacy weaknesses. A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePotential impact\u003c/td\u003e\u003ctd\u003eThe loss of confidentiality, integrity, or availability could be expected to have: (i) a limited adverse effect (FIPS 199 low); (ii) a serious adverse effect (FIPS 199 moderate); or (iii) a severe or catastrophic adverse effect (FIPS 199 high) on organizational operations, organizational assets, or individuals.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eProgram\u003c/td\u003e\u003ctd\u003eAn organized set of activities directed toward a goal or particular set of goals or objectives for which the program is accountable; a distinct set of activities and strategies organized toward achieving a specific purpose. A program is a representation of what is delivered to the public. Programs usually operate for indefinite or continuous periods, but may consist of several projects or initiatives.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eReportable condition\u0026nbsp;\u003c/td\u003e\u003ctd\u003eReportable conditions overall include a control deficiency, or combination of control deficiencies, that in management’s judgment, must be communicated because they represent significant weaknesses in the design or operation of an internal control that could adversely affect the organization’s ability to meet its internal control objectives.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eResilience\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs. [NIST SP 800-39, Adapted]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Information system-related security and privacy risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk accepted\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA status assigned when the weakness risk has been accepted. When assigning this status, an acceptance of the risk must be certified by the appropriate Authorizing Official and documented accordingly. The weakness and corresponding risk must be monitored periodically to ensure the associated risk remains at an acceptable level.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSafeguards\u0026nbsp;\u003c/td\u003e\u003ctd\u003eProtective measures prescribed to meet the security and privacy requirements specified for an information system. Safeguards may include security and privacy features, management constraints, personnel security, and security of physical structures, areas, and devices; synonymous with security and privacy controls and countermeasures.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eScheduled or estimated completion date\u003c/td\u003e\u003ctd\u003eA realistic estimate of the amount of time it will take to complete all associated milestones for a POA\u0026amp;M.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecurity Control Assessment (SCA)\u003c/td\u003e\u003ctd\u003eThe testing and/or evaluation of the management, operational, and technical security controls in an information system to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. [NIST SP 800-37]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecurity Control Inheritance\u003c/td\u003e\u003ctd\u003eA situation in which an information system or application receives protection from security and privacy controls (or portions of security and privacy controls) that are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides. See Common Control.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSignificant deficiency\u003c/td\u003e\u003ctd\u003eA weakness in an agency’s overall information systems security and privacy program or management control structure, or within one or more information systems, that significantly restricts the capability of the agency to carry out its mission or compromises the security or privacy of its information, information systems, personnel, or other resources, operations, or assets. In this context, the risk is great enough that the agency head and outside agencies must be notified and immediate or near-immediate corrective action must be taken.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eTechnical controls\u003c/td\u003e\u003ctd\u003eSecurity controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system. [FIPS 200]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eThreat\u003c/td\u003e\u003ctd\u003eAny potential danger to information or systems. A potential threat event, if realized, would cause an undesirable impact. The undesirable impact can come in many forms, but often results in a financial loss. A threat agent could be an intruder accessing the network through a port on the firewall, a process of accessing data in a way that violates that security or privacy policy, a tornado wiping out a facility, or an employee making an unintentional mistake that could expose confidential information or destroy a file’s integrity.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe absence or weakness of a safeguard that could be exploited; the absence or weakness of cumulative controls protecting a particular asset. Vulnerability is a software, hardware, or procedure weakness that may provide an attacker the open door he is looking for to enter a computer or network and have unauthorized access to resources within the environment.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eWaiver\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA status provided when the weakness risk has been accepted and justification has been appropriately documented. Justification of non- compliance must follow the agency's waiver policy and be documented accordingly.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eWeakness\u003c/td\u003e\u003ctd\u003eThe absence of adequate controls.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e"])</script><script>self.__next_f.push([1,"24b:T9cb3,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is a POA\u0026amp;M?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Plan of Action and Milestones (POA\u0026amp;M) is a corrective action plan that tracks system weakness and allows System Owners and ISSOs to create a plan to resolve the identified weaknesses over time. A POA\u0026amp;M provides details about the personnel, technology, and funding required to accomplish the elements of the plan, milestones for correcting the weaknesses, and scheduled completion dates for the milestones.\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePOA\u0026amp;M process overview\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe POA\u0026amp;M process begins when a weakness is identified in a CMS FISMA system. Working together, the System/Business Owner and the Authorizing Official (AO) are responsible for mitigating the risk posed by the weakness, with support from the Information System Security Officer (ISSO) and Cyber Risk Advisor (CRA). The steps to the POA\u0026amp;M process are outlined below, and will be described in greater detail throughout the remainder of this guide:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIdentify weaknesses\u003c/li\u003e\u003cli\u003eDevelop a Corrective Action Plan (CAP)\u003c/li\u003e\u003cli\u003eDetermine resource and funding availability\u003c/li\u003e\u003cli\u003eAssign a completion date\u003c/li\u003e\u003cli\u003eExecute the Corrective Action Plan (CAP)\u003c/li\u003e\u003cli\u003eVerify weakness completion\u003c/li\u003e\u003cli\u003eAccept risk when applicable\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eIdentifying weaknesses\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe term “weakness” represents any information security or privacy vulnerability that could be exploited as a result of a specific control deficiency. Weaknesses can compromise a system’s confidentiality, integrity, or availability. All weaknesses that represent risk to the security or privacy of a system must be corrected and the required mitigation efforts captured in a POA\u0026amp;M.\u0026nbsp;For the purpose of this document, the term “weakness” as defined in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53, rev. 5 \u003c/a\u003ewill be synonymous with the terms finding and vulnerability. These terms are defined below:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eFinding\u003c/strong\u003e – During an assessment or audit, the security and privacy controls of a system are tested, or exercised. A system either satisfies the requirements or a control or does not satisfy it.\u0026nbsp; Findings are the result of the assessment or audit. Findings that do not satisfy a control must be addressed with a POA\u0026amp;M.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eVulnerability\u003c/strong\u003e – A vulnerability is a weakness in a system, a system’s security procedures, its internal controls, or its implementation that could be exploited or triggered by a threat source.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eFinding weaknesses\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWeaknesses may be found during an internal or external audit, review, or through Continuous Diagnostics and Mitigation (CDM) efforts. There are a number of specific sources that help system teams identify weaknesses:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eHHS OIG Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eGovernment Accountability Office (GAO) Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eChief Financial Officer (CFO) Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eOMB A-123 Internal Control Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eAnnual Assessments\u003c/li\u003e\u003cli\u003eFISMA Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e or Security Control Assessments (SCA)\u0026nbsp;\u003c/li\u003e\u003cli\u003eMedicare Prescription Drug, Improvement, and Modernization Act of 2003 (MMA) Section 912 Audits\u0026nbsp;\u003c/li\u003e\u003cli\u003eInternal Revenue Service (IRS) Safeguard Reviews\u0026nbsp;\u003c/li\u003e\u003cli\u003eDepartment of Homeland Security (DHS) Risk Vulnerability Assessments (RVA)\u0026nbsp;\u003c/li\u003e\u003cli\u003eDHS Cyber Hygiene\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/penetration-testing\"\u003ePenetration Testing\u0026nbsp;\u003c/a\u003e\u003c/li\u003e\u003cli\u003eVulnerability Scanning\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eDuring these assessments, reviews, and audits, weaknesses can be found either proactively or reactively.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProactive - \u003c/strong\u003eProactive weakness identification occurs during regular system reviews conducted by CMS.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eReactive - \u003c/strong\u003eReactive weakness determination indicates that the weakness was identified during an audit or external review, like a penetration test.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWeaknesses are always documented by the source that identified them, and it’s important to indicate the identification source as you create your POA\u0026amp;M.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeakness severity levels\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere are three severity levels for all weaknesses discovered during assessments, audits, and tests. The risk the weakness poses to the agency’s overall security and privacy posture determines a weakness’ severity level . There are three levels of severity as defined by OMB: significant deficiency, reportable condition, and weakness.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWeakness severity levels\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eSignificant deficiency\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA weakness is considered a \u003cstrong\u003esignificant deficiency\u003c/strong\u003e if it drastically restricts the capability of the agency to carry out its mission or if it compromises the security or privacy of its information, information systems, personnel, or other resources, operations, or assets.\u0026nbsp;\u003c/p\u003e\u003cp\u003eSenior management must be notified and immediate or near immediate corrective action must be taken.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eReportable Condition\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA \u003cstrong\u003ereportable condition\u003c/strong\u003e is a weakness that affects the efficiency and effectiveness of agency operations.\u0026nbsp;\u003c/p\u003e\u003cp\u003eDue to its lower associated risk, corrective actions for a reportable condition may be scheduled over a longer period of time. The control auditor or assessor will make the determination that a weakness is a reportable condition.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWeakness\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eAll other weaknesses that do not rise to the level of a significant deficiency or reportable condition must be categorized as a weakness.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThey must be mitigated in a timely and efficient manner, as resources permit.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe weakness severity level can be obtained from the source or the audit report. Most findings will generally be categorized as a “weakness”. In the event that a weakness is designated as a “significant deficiency”, then contact the \u003ca href=\"mailto:ciso@cms.hhs.gov\"\u003eCISO mailbox \u003c/a\u003efor further guidance.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeakness risk level\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final\"\u003eNIST SP 800-30 \u003c/a\u003econtains the definitions and the practical guidance necessary for assessing and mitigating identified risks to IT systems. Risk level is dependent on multiple factors, such as \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFederal Information Processing Standard (FIPS) 199 \u003c/a\u003ecategory, operating environment, compensating controls, nature of the vulnerability, and impact if a system is compromised.\u003c/p\u003e\u003cp\u003eRisk can be evaluated either qualitatively or quantitatively and is typically expressed in its simplified form as:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRISK = THREAT x IMPACT x LIKELIHOOD\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe result of the analysis of the risk(s) from following the NIST SP 800-30 guide will recommend the overall risk level assigned to FISMA system of record.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eRoot Cause Analysis (RCA)\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll weaknesses must be examined to determine their root cause prior to documentation in the\u003c/p\u003e\u003cp\u003ePOA\u0026amp;M. \u003cstrong\u003eRoot Cause Analysis (RCA)\u003c/strong\u003e is an important and effective methodology used to correct information security or privacy weaknesses by eliminating the underlying cause. Various factors are reviewed to determine if they are the underlying cause of the weakness. Proper evaluation ensures the cause, not the symptom, is treated and prevents resources from being expended unnecessarily on addressing the same weakness.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003ePrioritizing weaknesses\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS takes a risk management approach to ensure that critical and high-impact weaknesses\u0026nbsp;\u003c/p\u003e\u003cp\u003etake precedence over lower security weaknesses. The following chart will help CMS System/Business Owners and ISSOs prioritize weaknesses on an ongoing basis to ensure that high-priority weaknesses receive the funding and the resources necessary to remediate or mitigate the most significant risks.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePrioritization factor\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDescription\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk level/severity\u003c/td\u003e\u003ctd\u003e\u003cp\u003eWeaknesses on a High or Moderate system or weaknesses that contribute to a material weakness, significant deficiency or reportable condition will normally require more immediate resolution.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis prioritization factor must consider the following elements:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eSensitivity and criticality of information on the system, such as personally identifiable information (PII).\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe estimated likelihood of the weakness occurring and/or being exploited.\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe cost of a potential occurrence or exploitation in terms of dollars, resources,, and/or reputation\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAnalysis\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe weakness must be analyzed to determine if there are any other processes or system relationships that it may affect.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eDoes the weakness fall within the system authorization boundary?\u0026nbsp;\u003c/li\u003e\u003cli\u003eIs it a potential program weakness?\u0026nbsp;\u003c/li\u003e\u003cli\u003eIs the weakness a systemic issue (across the enterprise) or is it an isolated event?\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSystemic issues represent much greater risk and may be a higher priority.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSource\u003c/td\u003e\u003ctd\u003eWhat is the source of the weakness? For example, if the weakness resulted from an audit and is considered a significant deficiency, then greater attention should be focused on this weakness.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVisibility\u003c/td\u003e\u003ctd\u003eHas the weakness drawn a high level of visibility external to the system or program? In some cases, a lower level weakness is a higher priority due to visibility. There are times when senior management or outside organizations focus on a specific weakness. Such weaknesses may take priority.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eRegardless of how the weakness is found and how severe it is,\u0026nbsp;it’s critical that system teams work together to create a Corrective Action Plan (CAP) to address it.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDevelop a Corrective Action Plan (CAP)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAfter weaknesses have been identified and the root cause has been determined, a \u003cstrong\u003eCorrective Action Plan (CAP)\u003c/strong\u003e must be developed. The CAP identifies:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe specific tasks, or “milestones”, that need to be accomplished to reduce or eliminate weakness\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe resources required to accomplish the plan\u003c/li\u003e\u003cli\u003eA timeline for correcting the weakness including a completion date\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe milestones in the CAP must provide specific, action-oriented descriptions of the tasks/steps that the stakeholder will take to mitigate the weakness. When creating your milestones, be sure that they are:\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSpecific\u003c/strong\u003e – target a specific area for improvement\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eMeasurable\u003c/strong\u003e – quantify or at least suggest an indicator of progress\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eAssignable\u003c/strong\u003e – specify who will do it\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRealistic\u003c/strong\u003e – state what results can realistically be achieved, given available resources\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eTime-related\u003c/strong\u003e – specify when the result(s) can be achieved.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe number of milestones written per weakness must directly correspond to the number of steps or corrective actions necessary to fully address and resolve the weakness. Each weakness must have at least one corresponding milestone with an estimated completion date and resource requirements to remediate the weakness. The chart below provides samples of compliant and non-compliant milestones that system teams can use when writing their CAP.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eExamples of appropriate milestones\u0026nbsp;\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePOA\u0026amp;M description\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eExample\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eMilestones with completion dates\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP)\u003c/td\u003e\u003ctd\u003eInappropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eEnsure vulnerability scanning covers the entire environment; (11/15/2018)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability scanning does not incorporate the entire environment as documented in the System Security and Privacy Plan (SSPP)\u003c/td\u003e\u003ctd\u003eAppropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eSchedule a review of the environment inventory; (11/15/2018)\u003c/li\u003e\u003cli\u003eUpdate the SSPP and the vulnerability scanner to reflect the updated inventory; (1/31/2019)\u003c/li\u003e\u003cli\u003eConduct a vulnerability scan to check that the entire inventory is included; (2/15/2019)\u003c/li\u003e\u003cli\u003eImplement an ongoing process to evaluate and update the inventory, the SSPP, and the vulnerability scans on a regular basis; (3/15/2019)\u003c/li\u003e\u003cli\u003ePerform a vulnerability scan and cross check the output with the updated inventory list to verify that the entire environment is included; (4/15/2019)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit logs are not periodically reviewed\u003c/td\u003e\u003ctd\u003eInappropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eEnsure that audit logs are periodically reviewed; (12/15/2018)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit logs are not periodically reviewed\u003c/td\u003e\u003ctd\u003eAppropriate\u003c/td\u003e\u003ctd\u003e\u003col\u003e\u003cli\u003eReview policy to ensure that audit log review is required; (12/15/2018)\u003c/li\u003e\u003cli\u003eIdentify the SO; (12/16/2018)\u003c/li\u003e\u003cli\u003eEstablish communication and training to convey the requirement of audit log review; (2/28/2019)\u003c/li\u003e\u003cli\u003eSchedule a follow-up review with the SO to ensure that audit log review is taking place. (3/31/2019)\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe CAP should be a collaborative effort with stakeholders including the CISO, System/Business Owners, System Developers and Maintainers, ISSOs, and others as needed. These stakeholders ensure that the CAP is created, executed, monitored, and worked to closure or risk-based acceptance.\u003c/p\u003e\u003cp\u003eOMB provides a standard POA\u0026amp;M format which is utilized at CMS. This structure improves the stakeholders’ ability to easily locate information and organize details for analysis. The CAP format includes a location for the identified program weakness, any associated milestones, and the necessary resources required.\u0026nbsp;\u003c/p\u003e\u003cp\u003eOnce the CAP is documented, the plan must be entered into \u003ca href=\"https://cfacts.cms.gov/\"\u003eCFACTS\u003c/a\u003e in the form of a series of milestone records. The status of the POA\u0026amp;M will automatically be moved from “draft” to “ongoing” 30 days after the weakness creation date. Once a milestone has been accepted/approved and closed, the record must be retained for one year.\u0026nbsp;\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eDetermine resource and funding availability\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eMaking funding decisions is often a collaborative exercise that involves multiple system personnel and stakeholders. Examples of questions to ask to determine if your team has the resources to appropriately respond to a weakness are:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eIs one team or person enough or will the participation of a larger team be needed?\u0026nbsp;\u003c/li\u003e\u003cli\u003eCan the task be accomplished within a week or will it take several months?\u0026nbsp;\u003c/li\u003e\u003cli\u003eHow serious is the weakness?\u0026nbsp;\u003c/li\u003e\u003cli\u003eWhat is this weakness’ risk level?\u0026nbsp;\u003c/li\u003e\u003cli\u003eHow complex is the CAP?\u0026nbsp;\u003c/li\u003e\u003cli\u003eDo we need to purchase equipment?\u003c/li\u003e\u003cli\u003eCan the weakness be addressed with existing funding or will we require new allocation from an existing budget source?\u0026nbsp;\u003c/li\u003e\u003cli\u003eWill my addressing this milestone require changes to existing policy or code?\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe System/Business Owner, ISSOs, and other stakeholders must ensure that adequate resources are allocated to mitigate or remediate weaknesses. They must also work together to determine the funding stream required to address the weakness, and any full-time equivalent (FTE) resources required to remediate or mitigate each weakness on the POA\u0026amp;M. The resources required for weakness remediation must fall into one of the following three categories:\u003c/p\u003e\u003col\u003e\u003cli\u003eUsing current resources allocated for the security and/or management of a program or system to complete remediation activities\u003c/li\u003e\u003cli\u003eReallocating existing funds that are appropriated and available for the remediation, or redirecting existing personnel\u003c/li\u003e\u003cli\u003eRequesting additional funding or personnel\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eDuplicate or similar weaknesses shall be documented in one POA\u0026amp;M, existing or new, to avoid inconsistencies. If a related POA\u0026amp;M already exists, the additional weakness shall be noted in the comment field.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eAssign a completion date\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eSystem/Business Owners, ISSOs, and other stakeholders must determine the scheduled completion date for each weakness using the criteria established by the remediation and mitigation timeline, the risk level, and the severity level. The milestone(s) completion date must not exceed the scheduled completion date assigned to the weakness.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIt is also a good practice to first determine the milestones with completion dates, as this will help determine a more accurate overall scheduled completion date for the weakness. The weakness schedule completion date is a calculated date. It is determined by the identified date and the risk level. The scheduled completion date established at the creation of the weakness must not be modified after the weakness is reported to OMB. POA\u0026amp;Ms become reportable once the status changes from “Draft” to “Ongoing” in CFACTS.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf a weakness is not remediated within the scheduled completion date, a new estimated completion date must be determined and documented in the Changes to Milestones and Comment fields in the POA\u0026amp;M in CFACTS.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNOTE: In use cases where a responsive and timely POA\u0026amp;M cannot be developed, the ISSO can choose to consider the Risk Based Decision (RBD) process to request the Authorizing Official (AO) to consider a risk acceptance until such time the vulnerability can be remediated.\u003c/em\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eExecute the Corrective Action Plan (CAP)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA designated Point of Contact (POC), responsible for ensuring proper execution of the CAP, must be identified for each weakness and its milestones. Individual(s) responsible for the execution of the CAP vary widely depending on the organization, system, milestones, and weakness.\u003c/p\u003e\u003cp\u003eThis POC resource will be key to identifying an “owner” of the milestone and ensuring the milestone is worked to the eventual remediation of the weakness or acceptable mitigation of the weakness. Once the planning of the necessary corrective action is complete and adequate resources have been made available, remediation or mitigation activities will proceed in accordance with the plan.\u003c/p\u003e\u003cp\u003eIf the completion of a milestone extends past its original estimated completion date, an update to the milestone and the completion date of the milestone must be captured in the “Changes to Milestone” field of CFACTS. If the scheduled completion date has passed before the weakness is remediated or mitigated, the weakness must default to “Delayed” status and a justification with a new estimated completion date must be documented in the “Comment” field and the “Changes to Milestone” field of the relevant weakness in CFACTS.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eVerify weakness completion\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCMS requires that all information in the POA\u0026amp;M be updated at least quarterly, ensuring accuracy for efficient tracking and reporting. As part of the review process, the ISSO will:\u003c/p\u003e\u003cul\u003e\u003cli\u003eValidate that the weakness is properly identified and prioritized\u003c/li\u003e\u003cli\u003eEnsure that appropriate resources have been made available to resolve the weakness\u003c/li\u003e\u003cli\u003eEnsure that the schedule for resolving the weakness is both appropriate and achievable\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eAccept risk when applicable\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA POA\u0026amp;M is a plan to resolve unacceptable risks. In rare cases, the Business Owner can present a case for accepting the risk to the AO or CIO, who may make the decision to accept the risk at their discretion. This is part of the Risk Based Decision (RBD) process. After approval, RBDs shall be reviewed at least annually to ensure the risk remains acceptable and updated as events occur and information changes. RBDs are managed in CFACTS under the \"RBD\" tab.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eClosing a POA\u0026amp;M\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePOA\u0026amp;Ms designated as Low and Moderate are closed by the ISSO and spot audited by a CRA.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms designed as Critical and High are closed by the CRA.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms generated from audits should be reviewed by the auditor prior to closure.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePOA\u0026amp;Ms resulting from a Penetration Test (PenTest) are closed by the PenTest team after the re-test has been performed.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eReports\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eReporting is a critical component of POA\u0026amp;M management, and CMS reports its remediation efforts on a monthly basis. The information in the POA\u0026amp;M must be maintained continuously to communicate overall progress. CMS must submit POA\u0026amp;M updates at least once a month (by the 3rd business day of each month) to HHS to demonstrate the status of POA\u0026amp;M mitigation or remediation activities.\u003c/p\u003e\u003cp\u003eCMS must submit the following information in accordance with the Department POA\u0026amp;M reporting requirements:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAll POA\u0026amp;Ms associated with a program, system and/or component that are within an authorization boundary. POA\u0026amp;Ms must be tied to the individual system and/or component and not the authorization boundary.\u003c/li\u003e\u003cli\u003eAn explanation associated with each delayed POA\u0026amp;M and a revised estimated completion date.\u003c/li\u003e\u003cli\u003eCompleted POA\u0026amp;Ms for up to one year from the date of completion.\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eWeakness remediation and mitigation timeline\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eAfter positive identification of scan findings or approval of security assessment and/or audit report, all findings/weaknesses shall be documented in a POA\u0026amp;M, reported to HHS, and remediated/mitigated within the following remediation timelines.\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eCritical within 15 days\u003c/li\u003e\u003cli\u003e\u0026nbsp;High within 30 days\u003c/li\u003e\u003cli\u003eModerate within 90 days\u003c/li\u003e\u003cli\u003eLow within 365 days\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eBusiness Owners, ISSOs, and/or other POA\u0026amp;M stakeholders must work together to determine the scheduled completion date for each POA\u0026amp;M within the specified remediation timelines. These timelines are based on the date the weakness is identified, not the date the POA\u0026amp;M is created. Stakeholders should complete and submit their CAAT templates in a timely manner to allow for the maximum time to complete the remediation/mitigation.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf it is determined that additional time is needed to remediate or mitigate a weakness, the justification with a modified estimated completion date shall be documented in the POA\u0026amp;M in the Changes to Milestones and Comment fields in CFACTS. If weaknesses are not remediated within the scheduled completion date, the status shall change to “Delayed”.\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWeaknesses discovered during a government audit\u0026nbsp;\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWeaknesses identified during a government audit (i.e., Inspector General or GAO audit) shall be documented in the POA\u0026amp;M after the audit draft report is produced, regardless of CMS acceptance of the identified weakness(es). Disagreements on findings that cannot be resolved between CMS and the auditing office shall be elevated to the Department for resolution. Systems must review and update POA\u0026amp;Ms at least quarterly. In addition, compensating controls must be in place and documented until weaknesses are remediated or mitigated to an acceptable level of risk.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eCFACTS\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eStakeholders must use\u0026nbsp;\u003ca href=\"https://cfacts.cms.gov/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eCFACTS\u003c/a\u003e, the CMS GRC tool, to identify, track, and manage all system weaknesses and associated POA\u0026amp;Ms to closure for CMS information systems. Users who need access to CFACTS may request an account and appropriate privileges through the Enterprise User Administration (EUA). The job code is \u003cstrong\u003eCFACTS_User_P\u003c/strong\u003e. Once the job code is assigned, the user must email the CISO mailbox at \u003ca href=\"mailto:ciso@cms.hhs.gov\"\u003eciso@cms.hhs.gov\u003c/a\u003e to notify the CISO of the user’s role (ISSO, System Developer, or System/Business Owner).\u003c/p\u003e\u003cp\u003eThe \u003cstrong\u003eCFACTS User Manual\u003c/strong\u003e provides detailed instructions for processing POA\u0026amp;M actions in the CFACTS tracking system. The User Manual can be accessed under the \u003cstrong\u003eCFACTS Documents\u003c/strong\u003e section on the \u003cstrong\u003eCFACTS Artifacts\u003c/strong\u003e page which can be accessed by clicking on the CFACTS Artifacts icon on the welcome page.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePOA\u0026amp;M Glossary\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe following glossary will help system teams understand the language of the POA\u0026amp;M process.\u003c/p\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eTerm\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDefinition\u0026nbsp;\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAnnual Assessment\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe process of validating the effective implementation of security and privacy controls in the information system and its environment of operation within every three hundred sixty-five (365) days in accordance with the CMS Information Security (IS) Acceptable Risk Safeguards (ARS) Including CMS Minimum Security Requirements (CMSR) Standard, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security and privacy requirements.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAudit\u003c/td\u003e\u003ctd\u003eAn independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCapital Planning and Investment Control\u003c/td\u003e\u003ctd\u003eA decision-making process for ensuring that investments integrate strategic planning, budgeting, procurement, and the management of or in support of Agency missions and business needs. [OMB Circular No. A-11]. The term comes from the Clinger-Cohen Act of 1996; while originally focused on IT, it now applies also to non-IT investments.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCommon Control\u003c/td\u003e\u003ctd\u003eA security or privacy control that is inherited by one or more organizational information systems. See Security Control Inheritance.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompleted\u003c/td\u003e\u003ctd\u003eA status assigned when all corrective actions have been completed or closed for a weakness and the weakness has been verified as successfully mitigated. Documentation is required to demonstrate the weakness has been adequately resolved. When assigning the status of ‘Completed’, the date of completion must also be included.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompletion date\u003c/td\u003e\u003ctd\u003eThe action date when all weaknesses have been fully resolved and the corrective action plan has been tested.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eControl activities\u003c/td\u003e\u003ctd\u003eThe policies and procedures that help ensure that management directives are carried out. They help ensure that necessary actions are taken to address risks to achievement of the entity’s objectives. Control activities, whether automated or manual, help achieve control objectives and are applied at various organizational and functional levels.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eControl deficiency\u003c/td\u003e\u003ctd\u003eA deficiency that exists when the design or operation of a control does not allow management or employees to, in the normal course of performing their assigned functions, prevent or detect breaches of confidentiality, integrity, or availability on a timely basis. (See also design deficiency or operations deficiency)\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCorrective Action Plan (CAP)\u003c/td\u003e\u003ctd\u003eThe plan management formulates to document the procedures and milestones identified to correct control deficiencies.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCriteria\u003c/td\u003e\u003ctd\u003e\u003cp\u003eA context for evaluating evidence and understanding the findings, conclusions, and recommendations included in the report. Criteria represent the laws, regulations, contracts, grant agreements, standards, specific requirements, measures, expected performance, defined business practices, and benchmarks against which performance is compared or evaluated.\u003c/p\u003e\u003cp\u003eCriteria identify the required or desired state or expectation with respect to the program or operation.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDelayed\u003c/td\u003e\u003ctd\u003eA status assigned when a weakness continues to be mitigated after the original scheduled completion date has passed. When assigning the status of ‘Delayed,’ an explanation must be provided in the milestone as to why the delay is occurring, as well as the revised completion date.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDesign deficiency\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA deficiency that exists when a control necessary to meet the control objective is missing or an existing control is not properly designed, so that even if the control operates as designed the control objective is not always met.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDraft\u003c/td\u003e\u003ctd\u003eA status that indicates that a weakness requires review and approval prior to “official” entry in the POA\u0026amp;M. Types of review that may take place while a weakness is in draft status would be: reviewing to determine if the weakness already exists and would be a duplicate; reviewing to determine if the organization will accept the risk, or apply for a waiver; etc.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eEvidence\u003c/td\u003e\u003ctd\u003eAny information used by the auditor, tester, or evaluator, to determine whether the information being audited, evaluated, or assessed is stated in accordance with the established criteria.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFISMA Audit\u003c/td\u003e\u003ctd\u003eA FISMA assessment designed to determine areas of compliance and areas requiring remediation to become FISMA compliant.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFederal Information Security Modernization Act (FISMA)\u003c/td\u003e\u003ctd\u003eRequires agencies to integrate information technology (IT) security into their capital planning and enterprise architecture processes at the agency, conduct annual IT security reviews of all programs and systems, and report the results of those reviews to the OMB. [NIST SP 800-65]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFindings\u003c/td\u003e\u003ctd\u003eConclusions based on an evaluation of sufficient, appropriate evidence against criteria.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInformation Security Risk\u003c/td\u003e\u003ctd\u003eThe risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and /or information systems.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePrimary Information System Security Officer (ISSO)\u003c/td\u003e\u003ctd\u003eIndividual with assigned responsibility for maintaining the appropriate operational security and privacy posture for an information system or program.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInitial audit findings\u003c/td\u003e\u003ctd\u003eAny type of audit conducted on a financial system or a non-financial system.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eInternal control\u003c/td\u003e\u003ctd\u003eAn integral component of an organization’s management systems that provides reasonable assurance that the following objectives are being achieved: effectiveness and efficiency of operations, reliability of financial reporting, or compliance with applicable laws and regulations.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eManagement controls\u003c/td\u003e\u003ctd\u003eThe security or privacy controls (i.e., safeguards or countermeasures) for an information system that focus on the management of risk and the management of information system security and privacy.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eMaterial weakness\u003c/td\u003e\u003ctd\u003eMaterial weaknesses includes reportable conditions in which the Secretary or Component Head determines to be significant enough to report outside of the Department. Material weakness in internal control over financial reporting is a reportable condition, or combination of reportable conditions, that results in more than a remote likelihood that a material misstatement of the financial statements, or other significant financial reports, will not be prevented or detected.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eMetrics\u0026nbsp;\u003c/td\u003e\u003ctd\u003eTools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance-related data.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eNon-conformance\u0026nbsp;\u003c/td\u003e\u003ctd\u003eInstances in which financial management systems do not substantially conform to financial systems requirements. Financial management systems include both financial and financially-related (or mixed) systems.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOngoing\u003c/td\u003e\u003ctd\u003eA status assigned when a weakness is in the process of being mitigated and has not yet exceeded the original scheduled completion date.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOperational controls\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe security or privacy controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by people (as opposed to systems).\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOperations deficiency\u003c/td\u003e\u003ctd\u003eA deficiency that exists when a properly designed control does not operate as designed or when the person performing the control is not qualified or properly skilled to perform the control effectively.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePending verification\u003c/td\u003e\u003ctd\u003eA status that indicates that all milestones/corrective actions have been completed but require review and sign-off to ensure effective resolution.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePlan of Action and Milestones (POA\u0026amp;M)\u003c/td\u003e\u003ctd\u003eA FISMA mandated corrective action plan to identify and resolve information security and privacy weaknesses. A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePotential impact\u003c/td\u003e\u003ctd\u003eThe loss of confidentiality, integrity, or availability could be expected to have: (i) a limited adverse effect (FIPS 199 low); (ii) a serious adverse effect (FIPS 199 moderate); or (iii) a severe or catastrophic adverse effect (FIPS 199 high) on organizational operations, organizational assets, or individuals.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eProgram\u003c/td\u003e\u003ctd\u003eAn organized set of activities directed toward a goal or particular set of goals or objectives for which the program is accountable; a distinct set of activities and strategies organized toward achieving a specific purpose. A program is a representation of what is delivered to the public. Programs usually operate for indefinite or continuous periods, but may consist of several projects or initiatives.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eReportable condition\u0026nbsp;\u003c/td\u003e\u003ctd\u003eReportable conditions overall include a control deficiency, or combination of control deficiencies, that in management’s judgment, must be communicated because they represent significant weaknesses in the design or operation of an internal control that could adversely affect the organization’s ability to meet its internal control objectives.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eResilience\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe ability to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs. [NIST SP 800-39, Adapted]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Information system-related security and privacy risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eRisk accepted\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA status assigned when the weakness risk has been accepted. When assigning this status, an acceptance of the risk must be certified by the appropriate Authorizing Official and documented accordingly. The weakness and corresponding risk must be monitored periodically to ensure the associated risk remains at an acceptable level.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSafeguards\u0026nbsp;\u003c/td\u003e\u003ctd\u003eProtective measures prescribed to meet the security and privacy requirements specified for an information system. Safeguards may include security and privacy features, management constraints, personnel security, and security of physical structures, areas, and devices; synonymous with security and privacy controls and countermeasures.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eScheduled or estimated completion date\u003c/td\u003e\u003ctd\u003eA realistic estimate of the amount of time it will take to complete all associated milestones for a POA\u0026amp;M.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecurity Control Assessment (SCA)\u003c/td\u003e\u003ctd\u003eThe testing and/or evaluation of the management, operational, and technical security controls in an information system to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. [NIST SP 800-37]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecurity Control Inheritance\u003c/td\u003e\u003ctd\u003eA situation in which an information system or application receives protection from security and privacy controls (or portions of security and privacy controls) that are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides. See Common Control.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSignificant deficiency\u003c/td\u003e\u003ctd\u003eA weakness in an agency’s overall information systems security and privacy program or management control structure, or within one or more information systems, that significantly restricts the capability of the agency to carry out its mission or compromises the security or privacy of its information, information systems, personnel, or other resources, operations, or assets. In this context, the risk is great enough that the agency head and outside agencies must be notified and immediate or near-immediate corrective action must be taken.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eTechnical controls\u003c/td\u003e\u003ctd\u003eSecurity controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system. [FIPS 200]\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eThreat\u003c/td\u003e\u003ctd\u003eAny potential danger to information or systems. A potential threat event, if realized, would cause an undesirable impact. The undesirable impact can come in many forms, but often results in a financial loss. A threat agent could be an intruder accessing the network through a port on the firewall, a process of accessing data in a way that violates that security or privacy policy, a tornado wiping out a facility, or an employee making an unintentional mistake that could expose confidential information or destroy a file’s integrity.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability\u0026nbsp;\u003c/td\u003e\u003ctd\u003eThe absence or weakness of a safeguard that could be exploited; the absence or weakness of cumulative controls protecting a particular asset. Vulnerability is a software, hardware, or procedure weakness that may provide an attacker the open door he is looking for to enter a computer or network and have unauthorized access to resources within the environment.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eWaiver\u0026nbsp;\u003c/td\u003e\u003ctd\u003eA status provided when the weakness risk has been accepted and justification has been appropriately documented. Justification of non- compliance must follow the agency's waiver policy and be documented accordingly.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eWeakness\u003c/td\u003e\u003ctd\u003eThe absence of adequate controls.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e"])</script><script>self.__next_f.push([1,"249:{\"value\":\"$24a\",\"format\":\"body_text\",\"processed\":\"$24b\",\"summary\":\"\"}\n24e:[]\n24d:{\"uri\":\"entity:node/561\",\"title\":\"CMS System Audits \",\"options\":\"$24e\",\"url\":\"/learn/system-audits\"}\n250:[]\n24f:{\"uri\":\"https://intranet.hhs.gov/document/standard-plans-action-and-milestones-poam-management-and-reporting\",\"title\":\"HHS Plan of Action and Milestones (POA\u0026M) guidance \",\"options\":\"$250\",\"url\":\"https://intranet.hhs.gov/document/standard-plans-action-and-milestones-poam-management-and-reporting\"}\n252:[]\n251:{\"uri\":\"entity:node/201\",\"title\":\"Cybersecurity and Risk Assessment Program (CSRAP)\",\"options\":\"$252\",\"url\":\"/learn/cybersecurity-risk-assessment-program-csrap\"}\n24c:[\"$24d\",\"$24f\",\"$251\"]\n253:{\"value\":\"A complete guide to creating, managing, and closing your system’s POA\u0026M\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eA complete guide to creating, managing, and closing your system’s POA\u0026amp;M\u003c/p\u003e\\n\"}\n247:{\"drupal_internal__nid\":401,\"drupal_internal__vid\":5866,\"langcode\":\"en\",\"revision_timestamp\":\"2024-08-13T19:41:02+00:00\",\"status\":true,\"title\":\"CMS Plan of Action and Milestones (POA\u0026M) Handbook\",\"created\":\"2022-08-29T16:59:47+00:00\",\"changed\":\"2024-08-05T15:55:04+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":\"$248\",\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":\"$249\",\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_last_reviewed\":\"2023-04-05\",\"field_related_resources\":\"$24c\",\"field_short_description\":\"$253\"}\n257:{\"drupal_internal__target_id\":\"library\"}\n256:{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":\"$257\"}\n259:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/node_type?resourceVersion=id%3A5866\"}\n25a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/node_ty"])</script><script>self.__next_f.push([1,"pe?resourceVersion=id%3A5866\"}\n258:{\"related\":\"$259\",\"self\":\"$25a\"}\n255:{\"data\":\"$256\",\"links\":\"$258\"}\n25d:{\"drupal_internal__target_id\":110}\n25c:{\"type\":\"user--user\",\"id\":\"a54cc91d-d38c-4158-9cf3-d7bcda34fc84\",\"meta\":\"$25d\"}\n25f:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/revision_uid?resourceVersion=id%3A5866\"}\n260:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/revision_uid?resourceVersion=id%3A5866\"}\n25e:{\"related\":\"$25f\",\"self\":\"$260\"}\n25b:{\"data\":\"$25c\",\"links\":\"$25e\"}\n263:{\"drupal_internal__target_id\":26}\n262:{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":\"$263\"}\n265:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/uid?resourceVersion=id%3A5866\"}\n266:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/uid?resourceVersion=id%3A5866\"}\n264:{\"related\":\"$265\",\"self\":\"$266\"}\n261:{\"data\":\"$262\",\"links\":\"$264\"}\n269:{\"drupal_internal__target_id\":91}\n268:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":\"$269\"}\n26b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/field_resource_type?resourceVersion=id%3A5866\"}\n26c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/field_resource_type?resourceVersion=id%3A5866\"}\n26a:{\"related\":\"$26b\",\"self\":\"$26c\"}\n267:{\"data\":\"$268\",\"links\":\"$26a\"}\n270:{\"drupal_internal__target_id\":66}\n26f:{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":\"$270\"}\n272:{\"drupal_internal__target_id\":61}\n271:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":\"$272\"}\n274:{\"drupal_internal__target_id\":76}\n273:{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":\"$274\"}\n26e:[\"$26f\",\"$271\",\"$273\"]\n276:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/lib"])</script><script>self.__next_f.push([1,"rary/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/field_roles?resourceVersion=id%3A5866\"}\n277:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/field_roles?resourceVersion=id%3A5866\"}\n275:{\"related\":\"$276\",\"self\":\"$277\"}\n26d:{\"data\":\"$26e\",\"links\":\"$275\"}\n27b:{\"drupal_internal__target_id\":16}\n27a:{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":\"$27b\"}\n27d:{\"drupal_internal__target_id\":11}\n27c:{\"type\":\"taxonomy_term--topics\",\"id\":\"0bc7c1d0-b569-4514-b66c-367457dead7e\",\"meta\":\"$27d\"}\n279:[\"$27a\",\"$27c\"]\n27f:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/field_topics?resourceVersion=id%3A5866\"}\n280:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/field_topics?resourceVersion=id%3A5866\"}\n27e:{\"related\":\"$27f\",\"self\":\"$280\"}\n278:{\"data\":\"$279\",\"links\":\"$27e\"}\n254:{\"node_type\":\"$255\",\"revision_uid\":\"$25b\",\"uid\":\"$261\",\"field_resource_type\":\"$267\",\"field_roles\":\"$26d\",\"field_topics\":\"$278\"}\n244:{\"type\":\"node--library\",\"id\":\"cba2b00b-3f53-42bd-8a60-f175e1d47a0a\",\"links\":\"$245\",\"attributes\":\"$247\",\"relationships\":\"$254\"}\n283:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d?resourceVersion=id%3A5777\"}\n282:{\"self\":\"$283\"}\n285:{\"alias\":\"/policy-guidance/cms-key-management-handbook\",\"pid\":993,\"langcode\":\"en\"}\n287:Tb185,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eBackground\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook aligns with the \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNational Institute of Standards and Technology (NIST) Special Publication (SP) 800-57\u003c/a\u003e series, the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS IS2P2\u003c/a\u003e, and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS Acceptable Risk Safeguards (ARS)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://security.cms.gov/learn/federal-information-systems-management-act-fisma\"\u003eFISMA\u003c/a\u003e further emphasizes the importance of continuously monitoring information system security by requiring agencies to conduct assessments of security controls at a risk-defined frequency. The CMS ARS states that CMS information systems must define, develop, disseminate, review, and update its Risk Assessment documentation at least once every three years or whenever a significant change has occurred. This includes a formal, documented system security/privacy package that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and formal, documented processes and procedures to facilitate the implementation of the policy and associated controls.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePolicy\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePolicy delineates the security management structure, clearly assigns security responsibilities, and lays the foundation necessary to reliably measure progress, compliance, and direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems or systems maintained on behalf of CMS to assure the confidentiality, integrity, and availability of CMS information and information systems.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eInformation Systems Security and Privacy Policy (IS2P2)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS IS2P2\u003c/a\u003e defines the framework and policy under which CMS protects and controls access to CMS information and information systems in compliance with the Department of Human and Health Services (HHS) policy, federal law, and regulations. This policy requires all CMS stakeholders to implement adequate information security and privacy safeguards to protect all CMS's sensitive information.\u003c/p\u003e\u003cp\u003eThe policies contained within the CMS IS2P2 assist in satisfying the requirements for controls that require CMS to create a policy and associated procedures related to information systems.\u003c/p\u003e\u003cp\u003eThe dynamic nature of information security and privacy disciplines and the constant need for assessing risk across the CMS environment can result in gaps in policy, outside of the routine policy review cycle. The CMS Policy Framework includes the option to issue a \u003ca href=\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/Policies\"\u003eCIO Directive\u003c/a\u003e to address these types of gaps in CMS policy by providing guidance to CMS stakeholders while a policy is being developed, updated, cleared, and approved.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eChief Information Officer (CIO) Directives\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CMS Chief Information Officer (CIO), the CMS Chief Information Security Officer (CISO), and the CMS Senior Official for Privacy (SOP) jointly develop and maintain the CMS IS2P2. The CIO delegates authority and responsibility to specific organizations and officials within CMS to develop and administer defined aspects of the CMS Information Security and Privacy Program as appropriate.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eStandards\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eStandards define both functional and assurance requirements within the CMS security and privacy environment. CMS policy is executed with the requirements prescribed in standards with the objective of enabling consistency across the CMS environment. The CMS environment includes users, networks, devices, all software, processes, information in storage or transit, applications, services, and systems that can be connected directly or indirectly to networks. These components are responsible for meeting and complying with the security and privacy baseline defined in policy and further prescribed in standards. The parameters and thresholds for policy implementation are built into the CMS standards, and provide a foundation for the procedural guidance provided by the Program Guide series.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eSecrets Management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eA secret is a digital authentication credential. Secrets are individually named sets of sensitive information, and address a broad spectrum of secure data. Secrets need to be protected against unauthorized disclosure, and all keys need to be protected against modification, tempering, deletion and disclosure. There are different types of secrets, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUser passwords\u003c/li\u003e\u003cli\u003eRoot passwords\u003c/li\u003e\u003cli\u003eApplication and database passwords\u003c/li\u003e\u003cli\u003eAuto-generated encryption keys\u003c/li\u003e\u003cli\u003ePrivate encryption keys\u003c/li\u003e\u003cli\u003eApplication Programming Interface (API) keys\u003c/li\u003e\u003cli\u003eApplication keys\u003c/li\u003e\u003cli\u003eSecure Shell (SSH) keys\u003c/li\u003e\u003cli\u003eIAM secret keys\u003c/li\u003e\u003cli\u003eProgrammatic access keys (project / client IDs)\u003c/li\u003e\u003cli\u003eAuthorization tokens\u003c/li\u003e\u003cli\u003eBearer tokens\u003c/li\u003e\u003cli\u003eCertificates\u003c/li\u003e\u003cli\u003ePrivate certificates (e.g. Transport Layer Security (TLS), Secure Sockets Layer (SSL))\u003c/li\u003e\u003cli\u003eRSA and other one-time password devices\u003c/li\u003e\u003cli\u003eAccount tags\u003c/li\u003e\u003cli\u003ePassphrases\u003c/li\u003e\u003cli\u003eAny other application tokens that are deemed confidential\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSecrets management refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.\u003c/p\u003e\u003cp\u003ePasswords and keys are some of the most broadly used and important tools your organization has for authenticating applications and users and providing them with access to sensitive systems, services, and information. Because secrets have to be transmitted securely, secrets management must account for and mitigate the risks to these secrets, both in transit and at rest.\u003c/p\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eNote – \u003c/strong\u003eRoot access keys should be protected at all costs and deleted if possible. A bad actor may shut down servers, delete data, create and destroy users, or any other API capability with the root user’s key. For this reason, CMS highly recommends that root access key should not be in use or should be disabled if already in use. CMS also recommends keeping the root user’s credentials safe and private. Do not share them with other employees or contractors. It is also advisable to activate Multi Factor Authentication (MFA) for the root account to protect it even if the password leaks. Also, access and secret access keys should only be developed at a user level, and never at a root level.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThe security objectives (Confidentiality, Integrity and Availability) should always be protected in regards to secrets management. The \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFederal Information Processing Standards (FIPS) Publication 199\u003c/a\u003e defines three levels of potential impact on organizations or individuals (low, moderate, high) should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability) and has additional examples on the impact of loss of one or more of the security objectives.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eKey Management\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eKey management refers to managing cryptographic keys within a cryptosystem. The term “cryptosystem” is shorthand for “cryptographic system” and refers to a computer system that employs cryptography, a method of protecting information and communications through the use of codes so that only those for whom the information is intended can read and process it.\u003c/p\u003e\u003cp\u003eCryptosystems deal with generating, exchanging, storing, using and replacing keys as needed at the user level.\u003c/p\u003e\u003cp\u003eThe security of the cryptosystem is dependent upon successful key management. Proper management ensures a key stays safe throughout its lifecycle, from generation and use to storing and deletion.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCryptographic Keys\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography.\u003c/p\u003e\u003cp\u003eWith effective cryptographic key management, data that is encrypted can still be protected even in the event of a breach, since encrypted data cannot be decrypted without the right keys. Proper usage of encryption and key management will assist an organization’s efforts to protect their data. \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendations for Key Management (Part 1, Revision 5) \u003c/em\u003e\u003c/a\u003eprovides an updated guideline for general cryptographic key management.\u003c/p\u003e\u003cp\u003eAt CMS, mechanisms are employed to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eProhibit the use of encryption keys that are not recoverable by authorized personnel\u003c/li\u003e\u003cli\u003eRequire senior management approval to authorize recovery of keys by someone other than the key owner\u003c/li\u003e\u003cli\u003eComply with approved cryptography standards mentioned in transit and at rest, as defined in the HHS Standard for Encryption of Computing Devices and Information, and in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAt CMS, cryptographic protection applies to both portable storage devices (e.g., USB memory sticks, CDs, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers). This applies to all digital assets like application software, Data Stores (Such as databases and file systems), Cloud Service, and Software As a Service.\u003c/p\u003e\u003cp\u003eWhen cryptographic mechanisms are needed, CMS information systems use encryption products that have been validated under the Cryptographic Module Validation Program to confirm compliance with \u003ca href=\"https://csrc.nist.gov/pubs/fips/140-2/upd2/final#:~:text=This%20Federal%20Information%20Processing%20Standard,of%20potential%20applications%20and%20environments.\"\u003eFederal Information Processing Standards (FIPS) 140-2\u003c/a\u003e in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Concepts\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eKey Management Phases\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePre-Operational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eOperational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePost-Operational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDestroyed Phase\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendation for Key Management: Part 1 - General\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003ein Section 8, there are four phases of key management:\u003c/p\u003e\u003col\u003e\u003cli\u003e\u003cstrong\u003ePre-operational phase\u003c/strong\u003e: The keying material is not yet available for normal cryptographic operations. Keys may not yet be generated or are in the pre-activation state. System or enterprise attributes are established during this phase as well.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eOperational phase\u003c/strong\u003e: The keying material is available and in normal use. Keys are in the active or suspended state. Keys in the active state may be designated as protect only, process only, or both protect and process; keys in the suspended state can be used for processing only.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePost-operational phase\u003c/strong\u003e: The keying material is no longer in normal use, but access to the keying material is possible, and the keying material may be used for processing protected information. Keys are in the deactivated or compromised states. Keys in the post-operational phase may be in an archive.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eDestroyed phase: \u003c/strong\u003eKeys are no longer available. Records of their existence may or may not have been deleted. Keys are in the destroyed state. Although the keys themselves may have been destroyed, the key’s metadata (e.g., key name, type, cryptoperiod, and usage period) may be retained. A cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect.\u003c/li\u003e\u003c/ol\u003e\u003ch4\u003e\u003cstrong\u003eKey Establishment\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey establishment is the process that results in the sharing of a key between two or more entities. This process could be by a manual distribution, by using automated key-transport or key agreement mechanisms, or by key derivation using an already-shared key between or among those entities. Key establishment processes include the creation of a key. Key establishment techniques and issues are discussed in Section 5.3 of \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/175/b/r1/final\"\u003eNIST SP 800-175B \u003cem\u003eGuideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms\u003c/em\u003e.\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Management Functions\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eRoles and responsibilities need to be defined for the CMS management of at least the following functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe generation or acquisition of key information (i.e., keying material and the associated metadata)\u003c/li\u003e\u003cli\u003eThe secure distribution of private keys, secret keys and the associated metadata\u003c/li\u003e\u003cli\u003eThe establishment of cryptoperiods\u003c/li\u003e\u003cli\u003eKey and/or certificate inventory management, including procedures for the routine supersession of keys and certificates at the end of a cryptoperiod or validity period\u003c/li\u003e\u003cli\u003eProcedures for the emergency revocation of compromised keys and the establishment (e.g., distribution) of replacement keys and/or certificates\u003c/li\u003e\u003cli\u003eAccounting for and the storage and recovery of the operational and backed-up copies of key information\u003c/li\u003e\u003cli\u003eThe storage and recovery of archived key information\u003c/li\u003e\u003cli\u003eProcedures for checking the integrity of stored key information before using it\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe destruction of private or secret keys that are no longer required\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eCryptographic Key Management Systems (CKMS)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe term cryptographic key management system (CKMS) refers to the framework and services that provide for the generation, establishment, control, accounting, and destruction of cryptographic keys and associated management information.\u003c/p\u003e\u003cp\u003eIt includes all elements (hardware, software, other equipment, and documentation); facilities; personnel; procedures; standards; and information products that form the system that establishes, manages, and supports cryptographic products and services for end entities.\u003c/p\u003e\u003cp\u003eA CKMS may handle symmetric keys, asymmetric keys or both. Key management policies, practice statements, and specifications should identify common CKMS elements and suggest functions of and relationships among the organizational elements responsible for the management and use of cryptographic keys.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-152.pdf\"\u003eNIST SP 800-152\u003c/a\u003e contains requirements for the design, implementation, and procurement of a CKMS for the CMS organization. A key management system can be designed to provide services for a single individual (e.g., in a personal data-storage system), an organization (e.g., in a secure Virtual Private Network (VPN) for intraoffice communications), or a large complex of organizations (e.g., in secure communications for the U.S. Government).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Planning\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final\"\u003eNIST SP.800-57 Part 2 Revision 1\u003c/a\u003e, CMS organizations are required by statutory and administrative rules and guidelines to protect the confidentiality and integrity of their sensitive information and processes. Federal agencies are required to determine a \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf\"\u003eFIPS 200\u003c/a\u003e impact level (i.e., Low, Moderate or High) based on the security categories defined in \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFIPS 199\u003c/a\u003e. The security categories are based on the potential impact on an organization if certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.\u003c/p\u003e\u003cp\u003eCMS encourages Application Development Organizations (ADOs) to utilize software solutions (both on premises and in the Cloud) that help with the creation, identification, management, retrieval, rotation, and removal of keys - especially when these products help ADOs to better comply with CMS key management policy and its requirements.\u003c/p\u003e\u003cp\u003eCMS organizations also need to define their security objectives for storing and/or communicating their sensitive information. These objectives may include the following:\u003c/p\u003e\u003cul\u003e\u003cli\u003eProviding confidentiality for stored and/or transmitted data,\u003c/li\u003e\u003cli\u003eSource authentication for received data,\u003c/li\u003e\u003cli\u003eIntegrity protection for stored/transmitted data,\u003c/li\u003e\u003cli\u003eEntity authentication, etc.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe development of new cryptographic systems, including CKMS, should ideally be conducted following the processes described in \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/160/v2/r1/ipd#:~:text=Draft%20NIST%20Special%20Publication%20(SP,systems%20from%20the%20inside%20out\"\u003eNIST SP 800-160 \u003cem\u003eDeveloping Cyber-Resilient Systems: A Systems Security Engineering Approach\u003c/em\u003e\u003c/a\u003e. However, in many cases, systems that rely on cryptographic protection are already being used. Where such systems are being augmented or otherwise modified, security/privacy planning is still required, but the NIST SP 800-160 processes will need to be abridged or otherwise adapted because of legacy constraints. CMS organizations must still select \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53\u003c/a\u003e, based on \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eARS 5.0\u003c/a\u003e Control Catalog, security/privacy controls based on system design, operational characteristics, and FIPS 199 impact levels.\u003c/p\u003e\u003cp\u003eKey management planning should involve the following steps:\u003c/p\u003e\u003col\u003e\u003cli\u003eAn appropriate key management architecture is selected based on the available cryptographic mechanisms and objectives. Section 2.3 of \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf\"\u003eNIST SP 800-57 Part. 2 Revision 1\u003c/a\u003e provides examples of architectures to be considered.\u003c/li\u003e\u003cli\u003eA Key Management Specification is developed for each cryptographic product to be used in the system. When developing a Key Management Specification for a cryptographic product, the unique key management products and services needed from the CKMS to support the operation of the cryptographic product must be defined. The specification of cryptographic mechanisms, including key management functions, should consider the CMS organization’s resource limitations and procedural environment. If a Key Management Plan already exists for a CMS organization, the Key Management Specification needs to be in conformance with the CKMS Security Policy. The CKMS Practice Statement should support both the CKMS Security Policy and the Key Management Specification.\u003c/li\u003e\u003cli\u003eBased on the Key Management Plan, a CKMS Security Policy (CKMS SP) is developed that documents the decisions made in developing the Key Management Plan. A CKMS SP is a set of rules that are established to describe the goals, responsibilities, and overall requirements for the management of cryptographic keying material throughout the entire key lifecycle.\u003c/li\u003e\u003cli\u003eA CKMS may be operated by the organization owning the information to be protected, or may be operated by another organization (e.g., under contract). The organization operating the CKMS develops a CKMS Practice Statement (CKMS PS). A CKMS PS specifies how key management procedures and techniques are used to enforce the CKMS SP.\u003c/li\u003e\u003c/ol\u003e\u003ch3\u003e\u003cstrong\u003eKey Strength\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS organizations should consider the following best practices:\u003c/p\u003e\u003cul\u003e\u003cli\u003eEstablish what the application's minimum computational resistance to attack should be. Understanding the minimum computational resistance to attack should take into consideration the sophistication of your adversaries, how long data needs to be protected, where data is stored and if it is exposed. Identifying the computational resistance to attack will inform engineers as to the minimum length of the cryptographic key required to protect data over the life of that data. Consult \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/131/a/r2/final\"\u003eNIST SP 800-131a \u003cem\u003eTransitioning the Use of Cryptographic Algorithms and Key Lengths\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003efor additional guidance on determining the appropriate key lengths for the algorithm of choice.\u003c/li\u003e\u003cli\u003eWhen encrypting keys for storage or distribution, always encrypt a cryptographic key with another key of equal or greater cryptographic strength.\u003c/li\u003e\u003cli\u003eChoose a key length that meets or exceeds the comparative strength of other algorithms in use within your system. Refer to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57\u003c/a\u003e Table 2.\u003c/li\u003e\u003cli\u003eFormulate a strategy for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices.\u003c/li\u003e\u003cli\u003eReview \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendation for Key Management \u003c/em\u003e\u003c/a\u003efor recommended guidelines on key strength for specific algorithm implementations.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePublic Key Infrastructure\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePublic key infrastructure (PKI), as stated in \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-32.pdf\"\u003eNIST Special Publication 800-32: \u003cem\u003eIntroduction to Public Key Technology and the Federal PKI Infrastructure\u003c/em\u003e\u003c/a\u003e, is the combination of software, encryption technologies, and services that enables enterprises to \u003ca href=\"https://playbooks.idmanagement.gov/fpki/\"\u003eprotect the security of their communications and business transactions on networks\u003c/a\u003e. PKI integrates digital certificates, public key cryptography, and \u003cstrong\u003ecertification authorities (CA)\u003c/strong\u003e into a complete enterprise-wide network security architecture.\u003c/p\u003e\u003cp\u003eAll public key certificates used at CMS are issued in accordance with Federal PKI policy and validated to the Federal PKI trust anchor when being used for user signing, encrypting purposes, authentication, and authorization.\u003c/p\u003e\u003cp\u003eThe CA is responsible for issuing a public key certificate for each identity, confirming that the identity has the appropriate credentials. \u003cem\u003e\u003cstrong\u003eNote - \u003c/strong\u003ecertification authority (CA) is similar to a notary. The CA confirms the identities of parties sending and receiving electronic payments or other communications.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eAt CMS, various Certificate Authority requests are available and processed through the Infrastructure and User Services Group - Division of Operations Management (IUSG-DOM).\u003c/p\u003e\u003cp\u003eThere are two ways to submit a CA request for a certificate:\u003c/p\u003e\u003cul\u003e\u003cli\u003eRequestor submits a request through the CMS Connect System.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eNote: \u003c/strong\u003eOnly users with a CMS USER ID who have access to or VPN to the CMS Network will be able to login to the Agency Solution for Customer Support (ASCS). If you do not have a CMS USER ID, see option #2 below to submit an email request.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eRequestor sends certificate request email to the \u003cstrong\u003eCMS - DOMSSLCert \u003c/strong\u003emailbox at \u003ca href=\"mailto:DOMSSLCert@cms.hhs.gov\"\u003eDOMSSLCert@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor inquiries on the type of certificate to request, contact the CMS - DOMSSLCert mailbox at \u003ca href=\"mailto:DOMSSLCert@cms.hhs.gov\"\u003eDOMSSLCert@cms.hhs.gov\u003c/a\u003e for assistance.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Usage\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePer NIST SP 800-57 Part 1 Revision 5: \u003cem\u003eRecommendation for Key Management\u003c/em\u003e, a single key should be used for only one purpose (e.g., encryption, integrity authentication, key wrapping, random bit generation, or digital signatures).\u003c/p\u003e\u003cp\u003eThere are several reasons for this:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.\u003c/li\u003e\u003cli\u003eLimiting the use of a key limits the damage that could be done if the key is compromised.\u003c/li\u003e\u003cli\u003eSome uses of keys interfere with each other. For example, the length of time the key may be required for each use and purpose. Retention requirements of the data may differ for different data types.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis recommendation permits the use of a private key-transport or key-agreement key to generate a digital signature for the following special case: When requesting the (initial) certificate for a static key-establishment key that was generated as specified in \u003ca href=\"https://csrc.nist.gov/pubs/fips/186-5/final\"\u003eFIPS 186-5\u003c/a\u003e, the corresponding private key may be used to sign the certificate request.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Lifecycle Best Practices\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eGeneration\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCryptographic keys should be generated within cryptographic modules with at least a \u003ca href=\"https://csrc.nist.gov/pubs/fips/140-2/upd2/final\"\u003eFIPS 140-2\u003c/a\u003e compliance. For explanatory purposes, consider the cryptographic module in which a key is generated to be the key-generating module.\u003c/p\u003e\u003cp\u003eAny random value required by the key-generating module should be generated within that module; that is, the Random Bit Generator that generates the random value should be implemented within cryptographic modules with at least a FIPS 140-2 compliance that generates the key.\u003c/p\u003e\u003cp\u003eHardware cryptographic modules are preferred over software cryptographic modules for protection.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eUse/Distribution\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe generated keys should be transported (when necessary) using secure channels and should be used by their associated cryptographic algorithm within at least a FIPS 140-2 compliant cryptographic module. For additional detail for the recommendations in this section refer to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/133/r2/final\"\u003eNIST Special Publication 800-133\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eKeys or secrets should be shared out of band and should never be sent with or alongside the data the secrets or keys they are protecting. Also, secrets shared out-of-band should be protected and not stored somewhere that can be easily compromised (like on a piece of paper on a user’s desk). Out of band sharing of keys should be deleted or destroyed immediately after use.\u003c/p\u003e\u003cp\u003eADOs should also consider using a Diffie-Hellman algorithm like Secure-Remote Procedure Call (S-RPC) for the sharing of keys when out of band sharing is not a viable option. \u003cem\u003e\u003cstrong\u003eNote\u003c/strong\u003e - The Diffie–Hellman (DH) Algorithm is \u003cstrong\u003ea key-exchange protocol \u003c/strong\u003ethat enables two parties communicating over public channel to establish a mutual secret without it being transmitted over the Internet. DH enables the two to use a public key to encrypt and decrypt their conversation or data using symmetric cryptography.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eExamples of how keys can be shared included:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUse a Key or Secrets Management System\u003c/li\u003e\u003cli\u003eUse a shared key store or password manager vault\u003c/li\u003e\u003cli\u003eUse of client-side encrypted pastebin or similar service\u003c/li\u003e\u003cli\u003eUse of a restricted document\u003c/li\u003e\u003cli\u003eSending encrypted data via email (CMS adheres to the encryption requirements in the \u003ca href=\"https://intranet.hhs.gov/sites/default/files/s3fs-public/s3fs-public/policies-guides-encryption.pdf\"\u003eHHS Standard for Encryption of Computing Devices and Information\u003c/a\u003e)\u003c/li\u003e\u003cli\u003eUsing a third-party, CMS approved storage service\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eADOs should document the method being used for the business or system owner. ADOs are also encouraged to use TLS Version 1.2 or 1.3 encryption standards for Data-in-transit.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eStorage\u003c/strong\u003e\u003c/h4\u003e\u003cul\u003e\u003cli\u003eADOs should document in a Key Management Plan where secrets are being stored, and that documentation should be made available to the business or system owner, and updated as needed but no less than annually. The documentation should be written per system, define types of secrets used, list all secret alias names, creation date, recommended rotation date, level of sensitivity/classification, recommended end of use, business owner, and secret manager. The secrets should be encrypted and stored separately using a KMS solution or service.\u003c/li\u003e\u003cli\u003eCMS strongly encourages ADOs to use “split knowledge” or “M of N” for very sensitive key storage so that one individual does not have sole access to a key\u003c/li\u003e\u003cli\u003eDevelopers must understand where cryptographic keys are stored within the application and understand what memory devices the keys are stored on.\u003c/li\u003e\u003cli\u003eKeys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules.\u003c/li\u003e\u003cli\u003eKeys should never be stored in plaintext format.\u003c/li\u003e\u003cli\u003eEnsure all keys are stored in a cryptographic vault, such as a hardware security module (HSM), or isolated cryptographic service or secret management services.\u003c/li\u003e\u003cli\u003eIf you are planning on storing keys in offline devices/databases, then encrypt the keys using Key Encryption Keys (KEKs) prior to the export of the key material. KEK length (and algorithm) should be equivalent to or greater in strength than the keys being protected.\u003c/li\u003e\u003cli\u003eEnsure that keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Authentication Code (MAC)).\u003c/li\u003e\u003cli\u003eEnsure that standard application-level code never reads or uses cryptographic keys in any way and use key management libraries.\u003c/li\u003e\u003cli\u003eEnsure that keys and cryptographic operation is done inside a secure cryptographic vault.\u003c/li\u003e\u003cli\u003eAll work should be done in the cryptographic vault (such as key access, encryption, decryption, signing, etc.).\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eEscrow and Backup\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eData that has been encrypted with lost cryptographic keys will never be recovered. Therefore, it is essential that the application incorporate a secure key backup capability, especially for applications that support data-at-rest encryption for long-term data stores.\u003c/p\u003e\u003cp\u003eWhen backing up keys, ensure that the database that is used to store the keys is encrypted using at least a FIPS 140-2 validated module. It is sometimes useful to escrow key material for use in investigations and for re-provisioning of key material to users in the event that the key is lost or corrupted.\u003c/p\u003e\u003cp\u003eNever escrow keys used for performing digital signatures, but consider the need to escrow keys that support encryption. Oftentimes, escrow can be performed by the Certificate Authority (CA) or key management system that provisions certificates and keys, however in some instances separate APIs must be implemented to allow the system to perform the escrow for the application.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eAccountability and Audit\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAccountability involves the identification of those that have access to, or control of, cryptographic keys throughout their lifecycles. Accountability can be an effective tool to help prevent key compromises and to reduce the impact of compromises once they are detected.\u003c/p\u003e\u003cp\u003eAt a minimum, the key management system should account for all individuals who are able to view plaintext cryptographic keys.\u003c/p\u003e\u003cp\u003eIn addition, more sophisticated key-management systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form.\u003c/p\u003e\u003cp\u003eAccountability provides three significant advantages:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIt aids in the determination of when the compromise could have occurred and what individuals could have been involved.\u003c/li\u003e\u003cli\u003eIt tends to protect against compromise, because individuals with access to the key know that their access to the key is known.\u003c/li\u003e\u003cli\u003eIt is very useful in recovering from a detected key compromise to know where the key was used and what data or other keys were protected by the compromised key.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCertain principles have been found to be useful in enforcing the accountability of cryptographic keys. These principles might not apply to all systems or all types of keys.\u003c/p\u003e\u003cp\u003eSome of the principles that apply to long-term keys controlled by humans include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUniquely identifying keys.\u003c/li\u003e\u003cli\u003eIdentifying the key user.\u003c/li\u003e\u003cli\u003eIdentifying the dates and times of key use, along with the data that is protected.\u003c/li\u003e\u003cli\u003eIdentifying other keys that are protected by a symmetric or private key. Two types of audit should be performed on key management systems:\u003c/li\u003e\u003cli\u003eThe security/privacy plan and the procedures that are developed to support the plan should be periodically audited to ensure that they continue to support the Key Management Policy in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final\"\u003eNIST SP 800-57\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eThe protective mechanisms employed should be periodically reassessed with respect to the level of security that they provide and are expected to provide in the future, and that the mechanisms correctly and effectively support the appropriate policies.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNew technology developments and attacks should be taken into consideration. On a more frequent basis, the actions of the humans that use, operate, and maintain the system should be reviewed to verify that the humans continue to follow established security/privacy procedures.\u003c/p\u003e\u003cp\u003eStrong cryptographic systems can be compromised by lax and inappropriate human actions. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks on the system.\u003c/p\u003e\u003cp\u003eAccountability and Audit ensures the security objectives (Confidentiality, Integrity and Availability) are maintained. Effective integrity can be maintained if ADOs incorporate logging and provide for audit trails so we can track who used keys or secrets, for what purpose, etc.\u003c/p\u003e\u003cp\u003eIntegrity of the keys supports non-repudiation.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Rotation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey rotation provides several benefits, which are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIn the event that a key is compromised, regular rotation limits the number of actual messages/systems vulnerable to compromise. If key version is suspected to be compromised, disable it and revoke access to it as soon as possible.\u003c/li\u003e\u003cli\u003eRegular key rotation ensures CMS systems are resilient to manual rotation, whether due to a security breach or the need to migrate application to a stronger cryptographic algorithm.\u003c/li\u003e\u003cli\u003eLimiting the number of messages encrypted with the same key version helps prevent attacks enabled by cryptanalysis. Cryptanalysis is the study of ciphertext, ciphers and cryptosystems with the aim of understanding how they work and finding and improving techniques for defeating or weakening them.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor symmetric encryption, CMS organizations should configure automation key rotation by setting a key rotation period and starting time when key is created.\u003c/p\u003e\u003cp\u003eFor asymmetric encryption, CMS organizations should always manually rotate keys, because the new public key must be distributed before the key pair can be used.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRecommended minimum frequency of key rotation \u003c/strong\u003e– Annually.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNote \u003c/em\u003e- The rotation schedule can be based on either the key's age or the number or volume of messages encrypted with a key version. \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf\"\u003eNIST SP 800-57 Recommendation for Key Management \u003c/a\u003edescribes cryptoperiods as a factor in determining an appropriate period for rotation.\u003c/p\u003e\u003cp\u003eIf responsible personnel have indications that keys have been compromised, they should manually rotate the keys and re-encrypt data that was encrypted by the compromised keys as soon as possible. To re-encrypt data, download the old data, decrypt it with the old key, encrypt the old data using the new key, and then re-upload the re-encrypted data.\u003c/p\u003e\u003cp\u003eCMS recommends Online Certificate Status Protocol (OCSP) over Certificate Lifecycle Management (CLM) because there can be latencies in the system where CLM may not have the most up to date revocations.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Revocation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt2/final\"\u003eNIST SP 800-57 Part 2 \u003cem\u003eRecommendation for Key Management: Part 2 – Best Practices for Key Management Organizations\u003c/em\u003e\u003c/a\u003e, symmetric keys are often revoked by the use of Compromised Key Lists (CKLs). Certificate Revocation Lists (CRLs) are commonly used to revoke public key certificates, thus revoking the private key corresponding to the public key in the certificate. Regardless of whether symmetric or asymmetric keys are used, a means of revoking keys is recommended.\u003c/p\u003e\u003cp\u003eThis CMS guide will use the term revoked key notification (RKN) to refer to a mechanism to revoke keys. An RKN may include the revocation reason and an indication of when the revocation was requested. The inclusion of the revocation reason can be useful in risk decisions regarding the information that was received or stored using those keys.\u003c/p\u003e\u003cp\u003eA key may also be suspended from use for a variety of reasons, such as an unknown status of the key or due to the key owner being temporarily unavailable (e.g., the key owner is on extended leave). In the case of a certificate suspension, the intent is to suspend the use of the public key included in the certificate (e.g., to not verify digital signatures or establish keys while the use of the certificate is suspended). This may be communicated to relying parties as an “on hold” revocation reason code in a CRL and in an OCSP response. The certificate may later be revoked (e.g., a compromise of the private key corresponding to the public key in the certificate was confirmed) or the certificate may be reactivated (e.g., the key has not been compromised or the owner returned to work).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCompromise of Keys\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey compromise occurs when the protective mechanisms for the key fail (e.g., the confidentiality, integrity, or association of the key to its owner fail;) and the key can no longer be trusted to provide the required security. It is the responsibility of an owner of a private or secret key to protect the confidentiality of that key. Reporting a possible key compromise is the responsibility of anyone suspecting that a key has been compromised (e.g., the key’s owner or an entity that observes that the data protected by that key has been compromised).\u003c/p\u003e\u003cp\u003eWhen a key is compromised, all use of the key to apply cryptographic protection to information (e.g., compute a digital signature or encrypt information) should cease, and the compromised key should be revoked.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eGuidelines to Minimize the Likelihood of a Key Compromise\u003c/strong\u003e\u003c/h4\u003e\u003cul\u003e\u003cli\u003ePeriodically rotate keys per the recommendation in this guide;\u003c/li\u003e\u003cli\u003eLimiting the amount of time that a secret symmetric or asymmetric private key is in plaintext form;\u003c/li\u003e\u003cli\u003ePreventing humans from viewing plaintext secret symmetric and asymmetric private keys;\u003c/li\u003e\u003cli\u003eRestricting plaintext secret and private keys to physically protected “containers.” This includes key generators, key-transport devices, key loaders, cryptographic modules, hardware security modules (HSMs), and key-storage devices;\u003c/li\u003e\u003cli\u003eUsing integrity checks to ensure that the integrity of a key or its association with other data has not been compromised. For example, keys may be wrapped (i.e., encrypted and integrity protected) in such a manner that unauthorized modifications to the wrapped key or to the key’s metadata will be detected;\u003cul\u003e\u003cli\u003eProviding a cryptographic integrity check on the key (e.g., using a MAC or a digital signature);\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eEmploying key confirmation to help ensure that the proper key was, in fact, established;\u003c/li\u003e\u003cli\u003eUsing trusted timestamps for signed data;\u003c/li\u003e\u003cli\u003eDestroying keys as soon as they are no longer needed; and\u003c/li\u003e\u003cli\u003eCreating a compromise-recovery plan, especially in the case of the compromise of a CA key.\u003c/li\u003e\u003cli\u003eData (key) dispersion - Data dispersion is recommended either through Redundant Array of Independent Disks (RAID) or use of erasure coding (bit splitting) in the Cloud. Data dispersion also addresses potential legal complications (for Cloud applications) that could arise should a server be confiscated by law enforcement. \u003cstrong\u003eNote -\u003c/strong\u003e\u003cem\u003e RAID (redundant array of independent disks) is a way of storing the same data in different places on multiple hard disks or solid-state drives (SSDs) to protect data in the case of a drive failure.\u003c/em\u003e\u003c/li\u003e\u003cli\u003eSSMS (Secret Sharing Made Short) is another standard protocol that is encouraged for key management within Cloud application. \u003cstrong\u003eNote -\u003c/strong\u003e \u003cem\u003eSSMS uses a three-phase process: encryption of information; use of information dispersal algorithm (IDA), which is designed to efficiently split the data using erasure coding into fragments; and splitting the encryption key itself using the secret-sharing algorithm.\u003c/em\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eA compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan should be documented and easily accessible. The plan may be included in a Key-Management Practices Statement39. If not, the Key-Management Practices Statement should reference the compromise-recovery plan.\u003c/p\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final\"\u003eNIST SP 800-57 Part 1 Rev. 5\u003c/a\u003e, a compromise-recovery plan should contain:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAn identification of the personnel to notify and what the notification should contain (e.g., the scope of the compromise − whether specific keys were compromised or the certificate generation process was compromised);\u003c/li\u003e\u003cli\u003eAn identification of the personnel to perform the recovery actions;\u003c/li\u003e\u003cli\u003eThe method for obtaining a new key (i.e., re-keying);\u003c/li\u003e\u003cli\u003eAn inventory of all cryptographic keys (e.g., the location of all keys and certificates in a system);\u003c/li\u003e\u003cli\u003eThe education of all appropriate personnel on the compromise-recovery procedures;\u003c/li\u003e\u003cli\u003eAn identification of all personnel needed to support the compromise-recovery procedures;\u003c/li\u003e\u003cli\u003ePolicies requiring that key-revocation checking be performed (to minimize the effect of a compromise);\u003c/li\u003e\u003cli\u003eThe monitoring of the re-keying operations (to ensure that all required operations are performed for all affected keys); and\u003c/li\u003e\u003cli\u003eAny other compromise-recovery procedures.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eOther compromise-recovery procedures may include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA physical inspection of the equipment;\u003c/li\u003e\u003cli\u003eAn identification of all information that may be compromised as a result of the incident;\u003c/li\u003e\u003cli\u003eAn identification of all signatures that may be invalid due to the compromise of a signing key; and\u003c/li\u003e\u003cli\u003eThe distribution of new keying material, if required.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eKey Archive and Key Recovery Functions\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eA key archive is a repository containing keys and their associated information (i.e., key information) for recovery beyond the cryptoperiod of the keys. Not all keys need to be archived. A CMS organization’s security/privacy plan should discuss key archiving.\u003c/p\u003e\u003cp\u003eAccess to key archive should be limited to authorized personnel/entities.\u003c/p\u003e\u003cp\u003eIf a key must be recoverable (e.g., after the end of its cryptoperiod), either the key should be archived, or the system should be designed to allow reconstruction (e.g., re-derivation) of the key from archived information. Retrieving the key from archive storage or by reconstruction is commonly known as key recovery. The archive should be maintained by a trusted party (e.g., the CMS organization associated with the key or a trusted third party).\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote -\u003c/strong\u003e \u003cem\u003eA cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys or a given system will remain in effect.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eNIST Special Publication \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf\"\u003e800-57 Part 1, Revision 5 \u003cem\u003eRecommendation for Key Management: Part 1 – General\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003efurther addresses the appropriateness of archiving keys and other cryptographically related information.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTrust Store\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eA trust store is a repository that contains cryptographic artifacts like certificates and private keys that are used for cryptographic protocols such as TLS. Because the compromise of a cryptographic key compromises all of the information and processes protected by that key, it is essential that client nodes be able to trust that keys and/or key components come from a trusted source, and that their confidentiality (if required) and integrity have been protected both in storage and in transit.\u003c/p\u003e"])</script><script>self.__next_f.push([1,"288:Tb185,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eBackground\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook aligns with the \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNational Institute of Standards and Technology (NIST) Special Publication (SP) 800-57\u003c/a\u003e series, the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS IS2P2\u003c/a\u003e, and the \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eCMS Acceptable Risk Safeguards (ARS)\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://security.cms.gov/learn/federal-information-systems-management-act-fisma\"\u003eFISMA\u003c/a\u003e further emphasizes the importance of continuously monitoring information system security by requiring agencies to conduct assessments of security controls at a risk-defined frequency. The CMS ARS states that CMS information systems must define, develop, disseminate, review, and update its Risk Assessment documentation at least once every three years or whenever a significant change has occurred. This includes a formal, documented system security/privacy package that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and formal, documented processes and procedures to facilitate the implementation of the policy and associated controls.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003ePolicy\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePolicy delineates the security management structure, clearly assigns security responsibilities, and lays the foundation necessary to reliably measure progress, compliance, and direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems or systems maintained on behalf of CMS to assure the confidentiality, integrity, and availability of CMS information and information systems.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eInformation Systems Security and Privacy Policy (IS2P2)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe \u003ca href=\"https://security.cms.gov/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"\u003eCMS IS2P2\u003c/a\u003e defines the framework and policy under which CMS protects and controls access to CMS information and information systems in compliance with the Department of Human and Health Services (HHS) policy, federal law, and regulations. This policy requires all CMS stakeholders to implement adequate information security and privacy safeguards to protect all CMS's sensitive information.\u003c/p\u003e\u003cp\u003eThe policies contained within the CMS IS2P2 assist in satisfying the requirements for controls that require CMS to create a policy and associated procedures related to information systems.\u003c/p\u003e\u003cp\u003eThe dynamic nature of information security and privacy disciplines and the constant need for assessing risk across the CMS environment can result in gaps in policy, outside of the routine policy review cycle. The CMS Policy Framework includes the option to issue a \u003ca href=\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/Policies\"\u003eCIO Directive\u003c/a\u003e to address these types of gaps in CMS policy by providing guidance to CMS stakeholders while a policy is being developed, updated, cleared, and approved.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eChief Information Officer (CIO) Directives\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CMS Chief Information Officer (CIO), the CMS Chief Information Security Officer (CISO), and the CMS Senior Official for Privacy (SOP) jointly develop and maintain the CMS IS2P2. The CIO delegates authority and responsibility to specific organizations and officials within CMS to develop and administer defined aspects of the CMS Information Security and Privacy Program as appropriate.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eStandards\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eStandards define both functional and assurance requirements within the CMS security and privacy environment. CMS policy is executed with the requirements prescribed in standards with the objective of enabling consistency across the CMS environment. The CMS environment includes users, networks, devices, all software, processes, information in storage or transit, applications, services, and systems that can be connected directly or indirectly to networks. These components are responsible for meeting and complying with the security and privacy baseline defined in policy and further prescribed in standards. The parameters and thresholds for policy implementation are built into the CMS standards, and provide a foundation for the procedural guidance provided by the Program Guide series.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eSecrets Management\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eA secret is a digital authentication credential. Secrets are individually named sets of sensitive information, and address a broad spectrum of secure data. Secrets need to be protected against unauthorized disclosure, and all keys need to be protected against modification, tempering, deletion and disclosure. There are different types of secrets, including:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUser passwords\u003c/li\u003e\u003cli\u003eRoot passwords\u003c/li\u003e\u003cli\u003eApplication and database passwords\u003c/li\u003e\u003cli\u003eAuto-generated encryption keys\u003c/li\u003e\u003cli\u003ePrivate encryption keys\u003c/li\u003e\u003cli\u003eApplication Programming Interface (API) keys\u003c/li\u003e\u003cli\u003eApplication keys\u003c/li\u003e\u003cli\u003eSecure Shell (SSH) keys\u003c/li\u003e\u003cli\u003eIAM secret keys\u003c/li\u003e\u003cli\u003eProgrammatic access keys (project / client IDs)\u003c/li\u003e\u003cli\u003eAuthorization tokens\u003c/li\u003e\u003cli\u003eBearer tokens\u003c/li\u003e\u003cli\u003eCertificates\u003c/li\u003e\u003cli\u003ePrivate certificates (e.g. Transport Layer Security (TLS), Secure Sockets Layer (SSL))\u003c/li\u003e\u003cli\u003eRSA and other one-time password devices\u003c/li\u003e\u003cli\u003eAccount tags\u003c/li\u003e\u003cli\u003ePassphrases\u003c/li\u003e\u003cli\u003eAny other application tokens that are deemed confidential\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSecrets management refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.\u003c/p\u003e\u003cp\u003ePasswords and keys are some of the most broadly used and important tools your organization has for authenticating applications and users and providing them with access to sensitive systems, services, and information. Because secrets have to be transmitted securely, secrets management must account for and mitigate the risks to these secrets, both in transit and at rest.\u003c/p\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eNote – \u003c/strong\u003eRoot access keys should be protected at all costs and deleted if possible. A bad actor may shut down servers, delete data, create and destroy users, or any other API capability with the root user’s key. For this reason, CMS highly recommends that root access key should not be in use or should be disabled if already in use. CMS also recommends keeping the root user’s credentials safe and private. Do not share them with other employees or contractors. It is also advisable to activate Multi Factor Authentication (MFA) for the root account to protect it even if the password leaks. Also, access and secret access keys should only be developed at a user level, and never at a root level.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThe security objectives (Confidentiality, Integrity and Availability) should always be protected in regards to secrets management. The \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFederal Information Processing Standards (FIPS) Publication 199\u003c/a\u003e defines three levels of potential impact on organizations or individuals (low, moderate, high) should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability) and has additional examples on the impact of loss of one or more of the security objectives.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eKey Management\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eKey management refers to managing cryptographic keys within a cryptosystem. The term “cryptosystem” is shorthand for “cryptographic system” and refers to a computer system that employs cryptography, a method of protecting information and communications through the use of codes so that only those for whom the information is intended can read and process it.\u003c/p\u003e\u003cp\u003eCryptosystems deal with generating, exchanging, storing, using and replacing keys as needed at the user level.\u003c/p\u003e\u003cp\u003eThe security of the cryptosystem is dependent upon successful key management. Proper management ensures a key stays safe throughout its lifecycle, from generation and use to storing and deletion.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCryptographic Keys\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography.\u003c/p\u003e\u003cp\u003eWith effective cryptographic key management, data that is encrypted can still be protected even in the event of a breach, since encrypted data cannot be decrypted without the right keys. Proper usage of encryption and key management will assist an organization’s efforts to protect their data. \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendations for Key Management (Part 1, Revision 5) \u003c/em\u003e\u003c/a\u003eprovides an updated guideline for general cryptographic key management.\u003c/p\u003e\u003cp\u003eAt CMS, mechanisms are employed to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eProhibit the use of encryption keys that are not recoverable by authorized personnel\u003c/li\u003e\u003cli\u003eRequire senior management approval to authorize recovery of keys by someone other than the key owner\u003c/li\u003e\u003cli\u003eComply with approved cryptography standards mentioned in transit and at rest, as defined in the HHS Standard for Encryption of Computing Devices and Information, and in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAt CMS, cryptographic protection applies to both portable storage devices (e.g., USB memory sticks, CDs, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers). This applies to all digital assets like application software, Data Stores (Such as databases and file systems), Cloud Service, and Software As a Service.\u003c/p\u003e\u003cp\u003eWhen cryptographic mechanisms are needed, CMS information systems use encryption products that have been validated under the Cryptographic Module Validation Program to confirm compliance with \u003ca href=\"https://csrc.nist.gov/pubs/fips/140-2/upd2/final#:~:text=This%20Federal%20Information%20Processing%20Standard,of%20potential%20applications%20and%20environments.\"\u003eFederal Information Processing Standards (FIPS) 140-2\u003c/a\u003e in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Concepts\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eKey Management Phases\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePre-Operational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eOperational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePost-Operational Phase\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eDestroyed Phase\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendation for Key Management: Part 1 - General\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003ein Section 8, there are four phases of key management:\u003c/p\u003e\u003col\u003e\u003cli\u003e\u003cstrong\u003ePre-operational phase\u003c/strong\u003e: The keying material is not yet available for normal cryptographic operations. Keys may not yet be generated or are in the pre-activation state. System or enterprise attributes are established during this phase as well.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eOperational phase\u003c/strong\u003e: The keying material is available and in normal use. Keys are in the active or suspended state. Keys in the active state may be designated as protect only, process only, or both protect and process; keys in the suspended state can be used for processing only.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePost-operational phase\u003c/strong\u003e: The keying material is no longer in normal use, but access to the keying material is possible, and the keying material may be used for processing protected information. Keys are in the deactivated or compromised states. Keys in the post-operational phase may be in an archive.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eDestroyed phase: \u003c/strong\u003eKeys are no longer available. Records of their existence may or may not have been deleted. Keys are in the destroyed state. Although the keys themselves may have been destroyed, the key’s metadata (e.g., key name, type, cryptoperiod, and usage period) may be retained. A cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect.\u003c/li\u003e\u003c/ol\u003e\u003ch4\u003e\u003cstrong\u003eKey Establishment\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey establishment is the process that results in the sharing of a key between two or more entities. This process could be by a manual distribution, by using automated key-transport or key agreement mechanisms, or by key derivation using an already-shared key between or among those entities. Key establishment processes include the creation of a key. Key establishment techniques and issues are discussed in Section 5.3 of \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/175/b/r1/final\"\u003eNIST SP 800-175B \u003cem\u003eGuideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms\u003c/em\u003e.\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Management Functions\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eRoles and responsibilities need to be defined for the CMS management of at least the following functions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe generation or acquisition of key information (i.e., keying material and the associated metadata)\u003c/li\u003e\u003cli\u003eThe secure distribution of private keys, secret keys and the associated metadata\u003c/li\u003e\u003cli\u003eThe establishment of cryptoperiods\u003c/li\u003e\u003cli\u003eKey and/or certificate inventory management, including procedures for the routine supersession of keys and certificates at the end of a cryptoperiod or validity period\u003c/li\u003e\u003cli\u003eProcedures for the emergency revocation of compromised keys and the establishment (e.g., distribution) of replacement keys and/or certificates\u003c/li\u003e\u003cli\u003eAccounting for and the storage and recovery of the operational and backed-up copies of key information\u003c/li\u003e\u003cli\u003eThe storage and recovery of archived key information\u003c/li\u003e\u003cli\u003eProcedures for checking the integrity of stored key information before using it\u0026nbsp;\u003c/li\u003e\u003cli\u003eThe destruction of private or secret keys that are no longer required\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eCryptographic Key Management Systems (CKMS)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe term cryptographic key management system (CKMS) refers to the framework and services that provide for the generation, establishment, control, accounting, and destruction of cryptographic keys and associated management information.\u003c/p\u003e\u003cp\u003eIt includes all elements (hardware, software, other equipment, and documentation); facilities; personnel; procedures; standards; and information products that form the system that establishes, manages, and supports cryptographic products and services for end entities.\u003c/p\u003e\u003cp\u003eA CKMS may handle symmetric keys, asymmetric keys or both. Key management policies, practice statements, and specifications should identify common CKMS elements and suggest functions of and relationships among the organizational elements responsible for the management and use of cryptographic keys.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-152.pdf\"\u003eNIST SP 800-152\u003c/a\u003e contains requirements for the design, implementation, and procurement of a CKMS for the CMS organization. A key management system can be designed to provide services for a single individual (e.g., in a personal data-storage system), an organization (e.g., in a secure Virtual Private Network (VPN) for intraoffice communications), or a large complex of organizations (e.g., in secure communications for the U.S. Government).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Planning\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final\"\u003eNIST SP.800-57 Part 2 Revision 1\u003c/a\u003e, CMS organizations are required by statutory and administrative rules and guidelines to protect the confidentiality and integrity of their sensitive information and processes. Federal agencies are required to determine a \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf\"\u003eFIPS 200\u003c/a\u003e impact level (i.e., Low, Moderate or High) based on the security categories defined in \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf\"\u003eFIPS 199\u003c/a\u003e. The security categories are based on the potential impact on an organization if certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.\u003c/p\u003e\u003cp\u003eCMS encourages Application Development Organizations (ADOs) to utilize software solutions (both on premises and in the Cloud) that help with the creation, identification, management, retrieval, rotation, and removal of keys - especially when these products help ADOs to better comply with CMS key management policy and its requirements.\u003c/p\u003e\u003cp\u003eCMS organizations also need to define their security objectives for storing and/or communicating their sensitive information. These objectives may include the following:\u003c/p\u003e\u003cul\u003e\u003cli\u003eProviding confidentiality for stored and/or transmitted data,\u003c/li\u003e\u003cli\u003eSource authentication for received data,\u003c/li\u003e\u003cli\u003eIntegrity protection for stored/transmitted data,\u003c/li\u003e\u003cli\u003eEntity authentication, etc.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe development of new cryptographic systems, including CKMS, should ideally be conducted following the processes described in \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/160/v2/r1/ipd#:~:text=Draft%20NIST%20Special%20Publication%20(SP,systems%20from%20the%20inside%20out\"\u003eNIST SP 800-160 \u003cem\u003eDeveloping Cyber-Resilient Systems: A Systems Security Engineering Approach\u003c/em\u003e\u003c/a\u003e. However, in many cases, systems that rely on cryptographic protection are already being used. Where such systems are being augmented or otherwise modified, security/privacy planning is still required, but the NIST SP 800-160 processes will need to be abridged or otherwise adapted because of legacy constraints. CMS organizations must still select \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53\u003c/a\u003e, based on \u003ca href=\"https://security.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eARS 5.0\u003c/a\u003e Control Catalog, security/privacy controls based on system design, operational characteristics, and FIPS 199 impact levels.\u003c/p\u003e\u003cp\u003eKey management planning should involve the following steps:\u003c/p\u003e\u003col\u003e\u003cli\u003eAn appropriate key management architecture is selected based on the available cryptographic mechanisms and objectives. Section 2.3 of \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf\"\u003eNIST SP 800-57 Part. 2 Revision 1\u003c/a\u003e provides examples of architectures to be considered.\u003c/li\u003e\u003cli\u003eA Key Management Specification is developed for each cryptographic product to be used in the system. When developing a Key Management Specification for a cryptographic product, the unique key management products and services needed from the CKMS to support the operation of the cryptographic product must be defined. The specification of cryptographic mechanisms, including key management functions, should consider the CMS organization’s resource limitations and procedural environment. If a Key Management Plan already exists for a CMS organization, the Key Management Specification needs to be in conformance with the CKMS Security Policy. The CKMS Practice Statement should support both the CKMS Security Policy and the Key Management Specification.\u003c/li\u003e\u003cli\u003eBased on the Key Management Plan, a CKMS Security Policy (CKMS SP) is developed that documents the decisions made in developing the Key Management Plan. A CKMS SP is a set of rules that are established to describe the goals, responsibilities, and overall requirements for the management of cryptographic keying material throughout the entire key lifecycle.\u003c/li\u003e\u003cli\u003eA CKMS may be operated by the organization owning the information to be protected, or may be operated by another organization (e.g., under contract). The organization operating the CKMS develops a CKMS Practice Statement (CKMS PS). A CKMS PS specifies how key management procedures and techniques are used to enforce the CKMS SP.\u003c/li\u003e\u003c/ol\u003e\u003ch3\u003e\u003cstrong\u003eKey Strength\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eCMS organizations should consider the following best practices:\u003c/p\u003e\u003cul\u003e\u003cli\u003eEstablish what the application's minimum computational resistance to attack should be. Understanding the minimum computational resistance to attack should take into consideration the sophistication of your adversaries, how long data needs to be protected, where data is stored and if it is exposed. Identifying the computational resistance to attack will inform engineers as to the minimum length of the cryptographic key required to protect data over the life of that data. Consult \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/131/a/r2/final\"\u003eNIST SP 800-131a \u003cem\u003eTransitioning the Use of Cryptographic Algorithms and Key Lengths\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003efor additional guidance on determining the appropriate key lengths for the algorithm of choice.\u003c/li\u003e\u003cli\u003eWhen encrypting keys for storage or distribution, always encrypt a cryptographic key with another key of equal or greater cryptographic strength.\u003c/li\u003e\u003cli\u003eChoose a key length that meets or exceeds the comparative strength of other algorithms in use within your system. Refer to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57\u003c/a\u003e Table 2.\u003c/li\u003e\u003cli\u003eFormulate a strategy for the overall organization's cryptographic strategy to guide developers working on different applications and ensure that each application's cryptographic capability meets minimum requirements and best practices.\u003c/li\u003e\u003cli\u003eReview \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"\u003eNIST SP 800-57 \u003cem\u003eRecommendation for Key Management \u003c/em\u003e\u003c/a\u003efor recommended guidelines on key strength for specific algorithm implementations.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003ePublic Key Infrastructure\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePublic key infrastructure (PKI), as stated in \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-32.pdf\"\u003eNIST Special Publication 800-32: \u003cem\u003eIntroduction to Public Key Technology and the Federal PKI Infrastructure\u003c/em\u003e\u003c/a\u003e, is the combination of software, encryption technologies, and services that enables enterprises to \u003ca href=\"https://playbooks.idmanagement.gov/fpki/\"\u003eprotect the security of their communications and business transactions on networks\u003c/a\u003e. PKI integrates digital certificates, public key cryptography, and \u003cstrong\u003ecertification authorities (CA)\u003c/strong\u003e into a complete enterprise-wide network security architecture.\u003c/p\u003e\u003cp\u003eAll public key certificates used at CMS are issued in accordance with Federal PKI policy and validated to the Federal PKI trust anchor when being used for user signing, encrypting purposes, authentication, and authorization.\u003c/p\u003e\u003cp\u003eThe CA is responsible for issuing a public key certificate for each identity, confirming that the identity has the appropriate credentials. \u003cem\u003e\u003cstrong\u003eNote - \u003c/strong\u003ecertification authority (CA) is similar to a notary. The CA confirms the identities of parties sending and receiving electronic payments or other communications.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eAt CMS, various Certificate Authority requests are available and processed through the Infrastructure and User Services Group - Division of Operations Management (IUSG-DOM).\u003c/p\u003e\u003cp\u003eThere are two ways to submit a CA request for a certificate:\u003c/p\u003e\u003cul\u003e\u003cli\u003eRequestor submits a request through the CMS Connect System.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003e\u003cstrong\u003eNote: \u003c/strong\u003eOnly users with a CMS USER ID who have access to or VPN to the CMS Network will be able to login to the Agency Solution for Customer Support (ASCS). If you do not have a CMS USER ID, see option #2 below to submit an email request.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eRequestor sends certificate request email to the \u003cstrong\u003eCMS - DOMSSLCert \u003c/strong\u003emailbox at \u003ca href=\"mailto:DOMSSLCert@cms.hhs.gov\"\u003eDOMSSLCert@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor inquiries on the type of certificate to request, contact the CMS - DOMSSLCert mailbox at \u003ca href=\"mailto:DOMSSLCert@cms.hhs.gov\"\u003eDOMSSLCert@cms.hhs.gov\u003c/a\u003e for assistance.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Usage\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003ePer NIST SP 800-57 Part 1 Revision 5: \u003cem\u003eRecommendation for Key Management\u003c/em\u003e, a single key should be used for only one purpose (e.g., encryption, integrity authentication, key wrapping, random bit generation, or digital signatures).\u003c/p\u003e\u003cp\u003eThere are several reasons for this:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.\u003c/li\u003e\u003cli\u003eLimiting the use of a key limits the damage that could be done if the key is compromised.\u003c/li\u003e\u003cli\u003eSome uses of keys interfere with each other. For example, the length of time the key may be required for each use and purpose. Retention requirements of the data may differ for different data types.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis recommendation permits the use of a private key-transport or key-agreement key to generate a digital signature for the following special case: When requesting the (initial) certificate for a static key-establishment key that was generated as specified in \u003ca href=\"https://csrc.nist.gov/pubs/fips/186-5/final\"\u003eFIPS 186-5\u003c/a\u003e, the corresponding private key may be used to sign the certificate request.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKey Management Lifecycle Best Practices\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eGeneration\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCryptographic keys should be generated within cryptographic modules with at least a \u003ca href=\"https://csrc.nist.gov/pubs/fips/140-2/upd2/final\"\u003eFIPS 140-2\u003c/a\u003e compliance. For explanatory purposes, consider the cryptographic module in which a key is generated to be the key-generating module.\u003c/p\u003e\u003cp\u003eAny random value required by the key-generating module should be generated within that module; that is, the Random Bit Generator that generates the random value should be implemented within cryptographic modules with at least a FIPS 140-2 compliance that generates the key.\u003c/p\u003e\u003cp\u003eHardware cryptographic modules are preferred over software cryptographic modules for protection.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eUse/Distribution\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe generated keys should be transported (when necessary) using secure channels and should be used by their associated cryptographic algorithm within at least a FIPS 140-2 compliant cryptographic module. For additional detail for the recommendations in this section refer to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/133/r2/final\"\u003eNIST Special Publication 800-133\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eKeys or secrets should be shared out of band and should never be sent with or alongside the data the secrets or keys they are protecting. Also, secrets shared out-of-band should be protected and not stored somewhere that can be easily compromised (like on a piece of paper on a user’s desk). Out of band sharing of keys should be deleted or destroyed immediately after use.\u003c/p\u003e\u003cp\u003eADOs should also consider using a Diffie-Hellman algorithm like Secure-Remote Procedure Call (S-RPC) for the sharing of keys when out of band sharing is not a viable option. \u003cem\u003e\u003cstrong\u003eNote\u003c/strong\u003e - The Diffie–Hellman (DH) Algorithm is \u003cstrong\u003ea key-exchange protocol \u003c/strong\u003ethat enables two parties communicating over public channel to establish a mutual secret without it being transmitted over the Internet. DH enables the two to use a public key to encrypt and decrypt their conversation or data using symmetric cryptography.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eExamples of how keys can be shared included:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUse a Key or Secrets Management System\u003c/li\u003e\u003cli\u003eUse a shared key store or password manager vault\u003c/li\u003e\u003cli\u003eUse of client-side encrypted pastebin or similar service\u003c/li\u003e\u003cli\u003eUse of a restricted document\u003c/li\u003e\u003cli\u003eSending encrypted data via email (CMS adheres to the encryption requirements in the \u003ca href=\"https://intranet.hhs.gov/sites/default/files/s3fs-public/s3fs-public/policies-guides-encryption.pdf\"\u003eHHS Standard for Encryption of Computing Devices and Information\u003c/a\u003e)\u003c/li\u003e\u003cli\u003eUsing a third-party, CMS approved storage service\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eADOs should document the method being used for the business or system owner. ADOs are also encouraged to use TLS Version 1.2 or 1.3 encryption standards for Data-in-transit.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eStorage\u003c/strong\u003e\u003c/h4\u003e\u003cul\u003e\u003cli\u003eADOs should document in a Key Management Plan where secrets are being stored, and that documentation should be made available to the business or system owner, and updated as needed but no less than annually. The documentation should be written per system, define types of secrets used, list all secret alias names, creation date, recommended rotation date, level of sensitivity/classification, recommended end of use, business owner, and secret manager. The secrets should be encrypted and stored separately using a KMS solution or service.\u003c/li\u003e\u003cli\u003eCMS strongly encourages ADOs to use “split knowledge” or “M of N” for very sensitive key storage so that one individual does not have sole access to a key\u003c/li\u003e\u003cli\u003eDevelopers must understand where cryptographic keys are stored within the application and understand what memory devices the keys are stored on.\u003c/li\u003e\u003cli\u003eKeys must be protected on both volatile and persistent memory, ideally processed within secure cryptographic modules.\u003c/li\u003e\u003cli\u003eKeys should never be stored in plaintext format.\u003c/li\u003e\u003cli\u003eEnsure all keys are stored in a cryptographic vault, such as a hardware security module (HSM), or isolated cryptographic service or secret management services.\u003c/li\u003e\u003cli\u003eIf you are planning on storing keys in offline devices/databases, then encrypt the keys using Key Encryption Keys (KEKs) prior to the export of the key material. KEK length (and algorithm) should be equivalent to or greater in strength than the keys being protected.\u003c/li\u003e\u003cli\u003eEnsure that keys have integrity protections applied while in storage (consider dual purpose algorithms that support encryption and Message Authentication Code (MAC)).\u003c/li\u003e\u003cli\u003eEnsure that standard application-level code never reads or uses cryptographic keys in any way and use key management libraries.\u003c/li\u003e\u003cli\u003eEnsure that keys and cryptographic operation is done inside a secure cryptographic vault.\u003c/li\u003e\u003cli\u003eAll work should be done in the cryptographic vault (such as key access, encryption, decryption, signing, etc.).\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eEscrow and Backup\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eData that has been encrypted with lost cryptographic keys will never be recovered. Therefore, it is essential that the application incorporate a secure key backup capability, especially for applications that support data-at-rest encryption for long-term data stores.\u003c/p\u003e\u003cp\u003eWhen backing up keys, ensure that the database that is used to store the keys is encrypted using at least a FIPS 140-2 validated module. It is sometimes useful to escrow key material for use in investigations and for re-provisioning of key material to users in the event that the key is lost or corrupted.\u003c/p\u003e\u003cp\u003eNever escrow keys used for performing digital signatures, but consider the need to escrow keys that support encryption. Oftentimes, escrow can be performed by the Certificate Authority (CA) or key management system that provisions certificates and keys, however in some instances separate APIs must be implemented to allow the system to perform the escrow for the application.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eAccountability and Audit\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAccountability involves the identification of those that have access to, or control of, cryptographic keys throughout their lifecycles. Accountability can be an effective tool to help prevent key compromises and to reduce the impact of compromises once they are detected.\u003c/p\u003e\u003cp\u003eAt a minimum, the key management system should account for all individuals who are able to view plaintext cryptographic keys.\u003c/p\u003e\u003cp\u003eIn addition, more sophisticated key-management systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form.\u003c/p\u003e\u003cp\u003eAccountability provides three significant advantages:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIt aids in the determination of when the compromise could have occurred and what individuals could have been involved.\u003c/li\u003e\u003cli\u003eIt tends to protect against compromise, because individuals with access to the key know that their access to the key is known.\u003c/li\u003e\u003cli\u003eIt is very useful in recovering from a detected key compromise to know where the key was used and what data or other keys were protected by the compromised key.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCertain principles have been found to be useful in enforcing the accountability of cryptographic keys. These principles might not apply to all systems or all types of keys.\u003c/p\u003e\u003cp\u003eSome of the principles that apply to long-term keys controlled by humans include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eUniquely identifying keys.\u003c/li\u003e\u003cli\u003eIdentifying the key user.\u003c/li\u003e\u003cli\u003eIdentifying the dates and times of key use, along with the data that is protected.\u003c/li\u003e\u003cli\u003eIdentifying other keys that are protected by a symmetric or private key. Two types of audit should be performed on key management systems:\u003c/li\u003e\u003cli\u003eThe security/privacy plan and the procedures that are developed to support the plan should be periodically audited to ensure that they continue to support the Key Management Policy in \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final\"\u003eNIST SP 800-57\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eThe protective mechanisms employed should be periodically reassessed with respect to the level of security that they provide and are expected to provide in the future, and that the mechanisms correctly and effectively support the appropriate policies.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNew technology developments and attacks should be taken into consideration. On a more frequent basis, the actions of the humans that use, operate, and maintain the system should be reviewed to verify that the humans continue to follow established security/privacy procedures.\u003c/p\u003e\u003cp\u003eStrong cryptographic systems can be compromised by lax and inappropriate human actions. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks on the system.\u003c/p\u003e\u003cp\u003eAccountability and Audit ensures the security objectives (Confidentiality, Integrity and Availability) are maintained. Effective integrity can be maintained if ADOs incorporate logging and provide for audit trails so we can track who used keys or secrets, for what purpose, etc.\u003c/p\u003e\u003cp\u003eIntegrity of the keys supports non-repudiation.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Rotation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey rotation provides several benefits, which are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIn the event that a key is compromised, regular rotation limits the number of actual messages/systems vulnerable to compromise. If key version is suspected to be compromised, disable it and revoke access to it as soon as possible.\u003c/li\u003e\u003cli\u003eRegular key rotation ensures CMS systems are resilient to manual rotation, whether due to a security breach or the need to migrate application to a stronger cryptographic algorithm.\u003c/li\u003e\u003cli\u003eLimiting the number of messages encrypted with the same key version helps prevent attacks enabled by cryptanalysis. Cryptanalysis is the study of ciphertext, ciphers and cryptosystems with the aim of understanding how they work and finding and improving techniques for defeating or weakening them.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor symmetric encryption, CMS organizations should configure automation key rotation by setting a key rotation period and starting time when key is created.\u003c/p\u003e\u003cp\u003eFor asymmetric encryption, CMS organizations should always manually rotate keys, because the new public key must be distributed before the key pair can be used.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRecommended minimum frequency of key rotation \u003c/strong\u003e– Annually.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNote \u003c/em\u003e- The rotation schedule can be based on either the key's age or the number or volume of messages encrypted with a key version. \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf\"\u003eNIST SP 800-57 Recommendation for Key Management \u003c/a\u003edescribes cryptoperiods as a factor in determining an appropriate period for rotation.\u003c/p\u003e\u003cp\u003eIf responsible personnel have indications that keys have been compromised, they should manually rotate the keys and re-encrypt data that was encrypted by the compromised keys as soon as possible. To re-encrypt data, download the old data, decrypt it with the old key, encrypt the old data using the new key, and then re-upload the re-encrypted data.\u003c/p\u003e\u003cp\u003eCMS recommends Online Certificate Status Protocol (OCSP) over Certificate Lifecycle Management (CLM) because there can be latencies in the system where CLM may not have the most up to date revocations.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eKey Revocation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/pubs/sp/800/57/pt2/final\"\u003eNIST SP 800-57 Part 2 \u003cem\u003eRecommendation for Key Management: Part 2 – Best Practices for Key Management Organizations\u003c/em\u003e\u003c/a\u003e, symmetric keys are often revoked by the use of Compromised Key Lists (CKLs). Certificate Revocation Lists (CRLs) are commonly used to revoke public key certificates, thus revoking the private key corresponding to the public key in the certificate. Regardless of whether symmetric or asymmetric keys are used, a means of revoking keys is recommended.\u003c/p\u003e\u003cp\u003eThis CMS guide will use the term revoked key notification (RKN) to refer to a mechanism to revoke keys. An RKN may include the revocation reason and an indication of when the revocation was requested. The inclusion of the revocation reason can be useful in risk decisions regarding the information that was received or stored using those keys.\u003c/p\u003e\u003cp\u003eA key may also be suspended from use for a variety of reasons, such as an unknown status of the key or due to the key owner being temporarily unavailable (e.g., the key owner is on extended leave). In the case of a certificate suspension, the intent is to suspend the use of the public key included in the certificate (e.g., to not verify digital signatures or establish keys while the use of the certificate is suspended). This may be communicated to relying parties as an “on hold” revocation reason code in a CRL and in an OCSP response. The certificate may later be revoked (e.g., a compromise of the private key corresponding to the public key in the certificate was confirmed) or the certificate may be reactivated (e.g., the key has not been compromised or the owner returned to work).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCompromise of Keys\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eKey compromise occurs when the protective mechanisms for the key fail (e.g., the confidentiality, integrity, or association of the key to its owner fail;) and the key can no longer be trusted to provide the required security. It is the responsibility of an owner of a private or secret key to protect the confidentiality of that key. Reporting a possible key compromise is the responsibility of anyone suspecting that a key has been compromised (e.g., the key’s owner or an entity that observes that the data protected by that key has been compromised).\u003c/p\u003e\u003cp\u003eWhen a key is compromised, all use of the key to apply cryptographic protection to information (e.g., compute a digital signature or encrypt information) should cease, and the compromised key should be revoked.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eGuidelines to Minimize the Likelihood of a Key Compromise\u003c/strong\u003e\u003c/h4\u003e\u003cul\u003e\u003cli\u003ePeriodically rotate keys per the recommendation in this guide;\u003c/li\u003e\u003cli\u003eLimiting the amount of time that a secret symmetric or asymmetric private key is in plaintext form;\u003c/li\u003e\u003cli\u003ePreventing humans from viewing plaintext secret symmetric and asymmetric private keys;\u003c/li\u003e\u003cli\u003eRestricting plaintext secret and private keys to physically protected “containers.” This includes key generators, key-transport devices, key loaders, cryptographic modules, hardware security modules (HSMs), and key-storage devices;\u003c/li\u003e\u003cli\u003eUsing integrity checks to ensure that the integrity of a key or its association with other data has not been compromised. For example, keys may be wrapped (i.e., encrypted and integrity protected) in such a manner that unauthorized modifications to the wrapped key or to the key’s metadata will be detected;\u003cul\u003e\u003cli\u003eProviding a cryptographic integrity check on the key (e.g., using a MAC or a digital signature);\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eEmploying key confirmation to help ensure that the proper key was, in fact, established;\u003c/li\u003e\u003cli\u003eUsing trusted timestamps for signed data;\u003c/li\u003e\u003cli\u003eDestroying keys as soon as they are no longer needed; and\u003c/li\u003e\u003cli\u003eCreating a compromise-recovery plan, especially in the case of the compromise of a CA key.\u003c/li\u003e\u003cli\u003eData (key) dispersion - Data dispersion is recommended either through Redundant Array of Independent Disks (RAID) or use of erasure coding (bit splitting) in the Cloud. Data dispersion also addresses potential legal complications (for Cloud applications) that could arise should a server be confiscated by law enforcement. \u003cstrong\u003eNote -\u003c/strong\u003e\u003cem\u003e RAID (redundant array of independent disks) is a way of storing the same data in different places on multiple hard disks or solid-state drives (SSDs) to protect data in the case of a drive failure.\u003c/em\u003e\u003c/li\u003e\u003cli\u003eSSMS (Secret Sharing Made Short) is another standard protocol that is encouraged for key management within Cloud application. \u003cstrong\u003eNote -\u003c/strong\u003e \u003cem\u003eSSMS uses a three-phase process: encryption of information; use of information dispersal algorithm (IDA), which is designed to efficiently split the data using erasure coding into fragments; and splitting the encryption key itself using the secret-sharing algorithm.\u003c/em\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eA compromise-recovery plan is essential for restoring cryptographic security services in the event of a key compromise. A compromise-recovery plan should be documented and easily accessible. The plan may be included in a Key-Management Practices Statement39. If not, the Key-Management Practices Statement should reference the compromise-recovery plan.\u003c/p\u003e\u003cp\u003eAccording to \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final\"\u003eNIST SP 800-57 Part 1 Rev. 5\u003c/a\u003e, a compromise-recovery plan should contain:\u003c/p\u003e\u003cul\u003e\u003cli\u003eAn identification of the personnel to notify and what the notification should contain (e.g., the scope of the compromise − whether specific keys were compromised or the certificate generation process was compromised);\u003c/li\u003e\u003cli\u003eAn identification of the personnel to perform the recovery actions;\u003c/li\u003e\u003cli\u003eThe method for obtaining a new key (i.e., re-keying);\u003c/li\u003e\u003cli\u003eAn inventory of all cryptographic keys (e.g., the location of all keys and certificates in a system);\u003c/li\u003e\u003cli\u003eThe education of all appropriate personnel on the compromise-recovery procedures;\u003c/li\u003e\u003cli\u003eAn identification of all personnel needed to support the compromise-recovery procedures;\u003c/li\u003e\u003cli\u003ePolicies requiring that key-revocation checking be performed (to minimize the effect of a compromise);\u003c/li\u003e\u003cli\u003eThe monitoring of the re-keying operations (to ensure that all required operations are performed for all affected keys); and\u003c/li\u003e\u003cli\u003eAny other compromise-recovery procedures.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eOther compromise-recovery procedures may include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eA physical inspection of the equipment;\u003c/li\u003e\u003cli\u003eAn identification of all information that may be compromised as a result of the incident;\u003c/li\u003e\u003cli\u003eAn identification of all signatures that may be invalid due to the compromise of a signing key; and\u003c/li\u003e\u003cli\u003eThe distribution of new keying material, if required.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eKey Archive and Key Recovery Functions\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eA key archive is a repository containing keys and their associated information (i.e., key information) for recovery beyond the cryptoperiod of the keys. Not all keys need to be archived. A CMS organization’s security/privacy plan should discuss key archiving.\u003c/p\u003e\u003cp\u003eAccess to key archive should be limited to authorized personnel/entities.\u003c/p\u003e\u003cp\u003eIf a key must be recoverable (e.g., after the end of its cryptoperiod), either the key should be archived, or the system should be designed to allow reconstruction (e.g., re-derivation) of the key from archived information. Retrieving the key from archive storage or by reconstruction is commonly known as key recovery. The archive should be maintained by a trusted party (e.g., the CMS organization associated with the key or a trusted third party).\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote -\u003c/strong\u003e \u003cem\u003eA cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys or a given system will remain in effect.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eNIST Special Publication \u003ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf\"\u003e800-57 Part 1, Revision 5 \u003cem\u003eRecommendation for Key Management: Part 1 – General\u003c/em\u003e\u003c/a\u003e\u003cem\u003e \u003c/em\u003efurther addresses the appropriateness of archiving keys and other cryptographically related information.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTrust Store\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eA trust store is a repository that contains cryptographic artifacts like certificates and private keys that are used for cryptographic protocols such as TLS. Because the compromise of a cryptographic key compromises all of the information and processes protected by that key, it is essential that client nodes be able to trust that keys and/or key components come from a trusted source, and that their confidentiality (if required) and integrity have been protected both in storage and in transit.\u003c/p\u003e"])</script><script>self.__next_f.push([1,"286:{\"value\":\"$287\",\"format\":\"body_text\",\"processed\":\"$288\",\"summary\":\"\"}\n28b:[]\n28a:{\"uri\":\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\",\"title\":\"NIST SP 800-57 Part 1 Rev. 5: Recommendations for Key Management\",\"options\":\"$28b\",\"url\":\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"}\n28d:[]\n28c:{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security and Privacy Policy (IS2P2)\",\"options\":\"$28d\",\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"}\n28f:[]\n28e:{\"uri\":\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/Policies\",\"title\":\"CMS Chief Information Officer (CIO) Policies \",\"options\":\"$28f\",\"url\":\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/Policies\"}\n289:[\"$28a\",\"$28c\",\"$28e\"]\n290:{\"value\":\"Guidance on the management lifecycle of cryptographic keys: data used to lock or unlock functions, including authentication, authorization, and encryption \",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eGuidance on the management lifecycle of cryptographic keys: data used to lock or unlock functions, including authentication, authorization, and encryption\u003c/p\u003e\\n\"}\n284:{\"drupal_internal__nid\":1141,\"drupal_internal__vid\":5777,\"langcode\":\"en\",\"revision_timestamp\":\"2024-08-05T16:04:17+00:00\",\"status\":true,\"title\":\"CMS Key Management Handbook \",\"created\":\"2023-08-23T13:26:44+00:00\",\"changed\":\"2024-08-05T16:04:17+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":\"$285\",\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":\"$286\",\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_last_reviewed\":\"2022-10-14\",\"field_related_resources\":\"$289\",\"field_short_description\":\"$290\"}\n294:{\"drupal_internal__target_id\":\"library\"}\n293:{\"type\":\"node_type--node_type\",\""])</script><script>self.__next_f.push([1,"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":\"$294\"}\n296:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/node_type?resourceVersion=id%3A5777\"}\n297:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/node_type?resourceVersion=id%3A5777\"}\n295:{\"related\":\"$296\",\"self\":\"$297\"}\n292:{\"data\":\"$293\",\"links\":\"$295\"}\n29a:{\"drupal_internal__target_id\":159}\n299:{\"type\":\"user--user\",\"id\":\"4420e728-6dc2-4022-bf8d-5bd1329e5e64\",\"meta\":\"$29a\"}\n29c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/revision_uid?resourceVersion=id%3A5777\"}\n29d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/revision_uid?resourceVersion=id%3A5777\"}\n29b:{\"related\":\"$29c\",\"self\":\"$29d\"}\n298:{\"data\":\"$299\",\"links\":\"$29b\"}\n2a0:{\"drupal_internal__target_id\":26}\n29f:{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":\"$2a0\"}\n2a2:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/uid?resourceVersion=id%3A5777\"}\n2a3:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/uid?resourceVersion=id%3A5777\"}\n2a1:{\"related\":\"$2a2\",\"self\":\"$2a3\"}\n29e:{\"data\":\"$29f\",\"links\":\"$2a1\"}\n2a6:{\"drupal_internal__target_id\":91}\n2a5:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":\"$2a6\"}\n2a8:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/field_resource_type?resourceVersion=id%3A5777\"}\n2a9:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/field_resource_type?resourceVersion=id%3A5777\"}\n2a7:{\"related\":\"$2a8\",\"self\":\"$2a9\"}\n2a4:{\"data\":\"$2a5\",\"links\":\"$2a7\"}\n2ad:{\"drupal_internal__target_id\":66}\n2ac:{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":\"$2ad\"}\n2af:{\"drupal_internal__target_id\":8"])</script><script>self.__next_f.push([1,"1}\n2ae:{\"type\":\"taxonomy_term--roles\",\"id\":\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\",\"meta\":\"$2af\"}\n2b1:{\"drupal_internal__target_id\":61}\n2b0:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":\"$2b1\"}\n2b3:{\"drupal_internal__target_id\":76}\n2b2:{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":\"$2b3\"}\n2b5:{\"drupal_internal__target_id\":71}\n2b4:{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"meta\":\"$2b5\"}\n2ab:[\"$2ac\",\"$2ae\",\"$2b0\",\"$2b2\",\"$2b4\"]\n2b7:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/field_roles?resourceVersion=id%3A5777\"}\n2b8:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/field_roles?resourceVersion=id%3A5777\"}\n2b6:{\"related\":\"$2b7\",\"self\":\"$2b8\"}\n2aa:{\"data\":\"$2ab\",\"links\":\"$2b6\"}\n2bc:{\"drupal_internal__target_id\":16}\n2bb:{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":\"$2bc\"}\n2be:{\"drupal_internal__target_id\":36}\n2bd:{\"type\":\"taxonomy_term--topics\",\"id\":\"65ef6410-4066-4db4-be03-c8eb26b63305\",\"meta\":\"$2be\"}\n2ba:[\"$2bb\",\"$2bd\"]\n2c0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/field_topics?resourceVersion=id%3A5777\"}\n2c1:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/field_topics?resourceVersion=id%3A5777\"}\n2bf:{\"related\":\"$2c0\",\"self\":\"$2c1\"}\n2b9:{\"data\":\"$2ba\",\"links\":\"$2bf\"}\n291:{\"node_type\":\"$292\",\"revision_uid\":\"$298\",\"uid\":\"$29e\",\"field_resource_type\":\"$2a4\",\"field_roles\":\"$2aa\",\"field_topics\":\"$2b9\"}\n281:{\"type\":\"node--library\",\"id\":\"596fc706-aa93-4b33-84a6-e648cf6c563d\",\"links\":\"$282\",\"attributes\":\"$284\",\"relationships\":\"$291\"}\n2c4:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015?resourceVersion=id%3A5712\"}\n2c3:{\"self\":\"$2c4\"}\n2c6:{\"alias\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook\",\"pid\":356,\"l"])</script><script>self.__next_f.push([1,"angcode\":\"en\"}\n2c8:T12321,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook gives practical guidance to Information System Security Officers (ISSO)s at CMS when performing their necessary tasks.\u0026nbsp; It helps new ISSOs get started and explains the responsibilities, resources, and organizational relationships needed for an ISSO to be successful.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis guide is for CMS (Federal) ISSOs, Contractor ISSOs, and contract security support individuals.\u0026nbsp; Business Owners and their staff may also find parts of this handbook useful, particularly when appointing new ISSOs or gaining a better understanding of ISSO tasks.\u003c/p\u003e\u003cp\u003eThe ISSO role is critical to the safe and authorized use of sensitive information in support of CMS’ commitment to improving healthcare for millions of Americans. As an ISSO,\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat do ISSOs do?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eEvery CMS system must formally designate an ISSO who serves as the primary point of contact responsible for the system’s security and privacy.\u0026nbsp;\u003c/p\u003e\u003cp\u003eISSOs at CMS are responsible for overseeing the security and privacy posture of the system(s) entrusted to their care, coordinating all information system risk management and information privacy activities, and acting as the Business Owner’s “go-to person” for security questions and needs. Together, the ISSOs make up a supportive community working to ensure the success of the cybersecurity program at CMS.\u003c/p\u003e\u003cp\u003eFor more details, see the section on role and responsibilities.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho do ISSOs work with?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO is part of the\u003cstrong\u003e portfolio team\u003c/strong\u003e – the group of people who work together to make sure that any given CMS information system complies with federal security requirements and is managed in a way that protects the personal and health information of those who depend on CMS for benefits. The portfolio team has the following roles:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProgram Executive, Information System Owner (ISO), Business Owner (BO), and Information System Security Officer (ISSO)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThese people work together to take full responsibility for implementing the required security and privacy controls and managing the cybersecurity and privacy risk posture for each system. All of these roles must be an agency official (federal government employee) except the ISSO, which may be a federal employee or a contractor.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCyber Risk Advisor (CRA)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eCRAs are the “go-to” experts in all areas of risk management, and as such they evaluate and communicate the risk posture of each FISMA system to executive leadership and make risk-based recommendations to the Authorizing Official. CRAs also help to identify the types of information processed by a system, assign the appropriate security categorizations, determine the privacy impacts, and manage information security and privacy risk. They facilitate the completion of all federal cybersecurity and privacy requirements – and this means that CRAs and ISSOs often work closely together.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eData Guardian\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Data Guardian coordinates CMS Program activities involving beneficiary and other types of consumer information that require privacy protections.\u0026nbsp; The Data Guardian must be an agency official (federal government employee) and must fulfill shared responsibilities with the CMS Business Owner.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePrivacy Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Privacy Advisor is a member of ISPG who provides privacy-related expertise to help the team identify and manage privacy risk.\u0026nbsp; The Privacy Advisor is an agency official (federal government employee) and serves as a point of contact for issues related to the Privacy Act. They also support the completion of privacy-related artifacts such as Systems of Records Notice (SORN), Privacy Act reviews, and FISMA and Privacy Management Report.\u003c/p\u003e\u003cp\u003eDetailed information about all of these roles can be found in the CMS Information Security and Privacy Policy (IS2P2) and the HHS Policy for Information Security and Privacy Protection (IS2P).\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat should an ISSO know?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe goal of every ISSO should be to support the BO to securely provide the service intended by the system. To help accomplish this goal, an ISSO should ideally know and understand their component’s business processes and how the system supports that business. This knowledge is critically applied during the construction of the System Security and Privacy Plan (SSPP).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eInformation security is a means to an end and not the end in itself\u003c/strong\u003e. In the public sector, information security is secondary to the agency's services provided to its constituency. We, as security professionals, must not lose sight of these goals and objectives.\u003c/p\u003e\u003cp\u003eIn order to help the BO provide a CMS service in a manner that is demonstrably secure and safeguards any sensitive beneficiary information, the ISSO must know (at a minimum):\u003c/p\u003e\u003cul\u003e\u003cli\u003eMission and business functions of their component\u003c/li\u003e\u003cli\u003eHow the system supports the component’s mission\u003c/li\u003e\u003cli\u003eSystem details, including:\u003cul\u003e\u003cli\u003eArchitecture\u003c/li\u003e\u003cli\u003eSystem components (hardware, software, peripherals, etc.)\u003c/li\u003e\u003cli\u003eLocation of each system component\u003c/li\u003e\u003cli\u003eData flow\u003c/li\u003e\u003cli\u003eInterconnections (internal and external)\u003c/li\u003e\u003cli\u003eSecurity categorization\u0026nbsp;\u003c/li\u003e\u003cli\u003eSecurity requirements\u003c/li\u003e\u003cli\u003eConfiguration management processes and procedures\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eUsers (how many, location, role, etc.)\u003c/li\u003e\u003cli\u003eKey personnel by name\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eHow are ISSOs appointed?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CMS Program Executive in coordination with the Data Guardian, ISO, and Business Owner, is responsible for nominating appropriately qualified ISSO appointees, as defined under FISMA, to the CISO for approval.\u003c/p\u003e\u003cp\u003eThe nominated ISSO, by signing the appointment letter, agrees to maintain the appropriate operational security posture of the information system by fulfilling all of the responsibilities identified in the \u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS Information Security and Privacy Policy (IS2P2)\u003c/a\u003e and the HHS Policy for Information Security and Privacy Protection (IS2P).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eA subset of the ISSO’s duties and responsibilities is contained in the \u003ca href=\"/learn/isso-appointment-letter\"\u003eappointment letter\u003c/a\u003e. ISSO letters must be updated whenever a change occurs. The designated ISSO should be consistently identified in three sources: the ISSO letter, the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e, and in \u003ca href=\"/learn/cms-fisma-continuous-tracking-system-cfacts\"\u003eCFACTS\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe signed appointment letter should be given to the appropriate CRA for further action.\u0026nbsp;\u003cstrong\u003e It is the responsibility of the CRA to upload the letter to CFACTS\u003c/strong\u003e.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eGetting started (for new ISSOs)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCongratulations on your new assignment as an Information System Security Officer (ISSO) at CMS! Because you are charged with protecting the sensitive information contained in systems that support healthcare delivery for millions of people, your role is vital to the success of CMS’ mission. You will learn how to identify and protect information that includes:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePersonally Identifiable Information (PII)\u003c/li\u003e\u003cli\u003eIndividually Identifiable Information (IIF)\u003c/li\u003e\u003cli\u003eProtected Health Information (PHI)\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis means that security must become a vital part of your daily routine and always top-of-mind. Your training as an ISSO will ensure that you know and understand the requirements for protecting government assets like classified information, property, and personnel.\u003c/p\u003e\u003cp\u003eMost importantly, you will learn to work as part of a team that is dedicated to making sure CMS information systems can operate securely. While CMS has established a security program to protect assets and keep sensitive information safe, the key ingredient is always \u003cstrong\u003epeople\u003c/strong\u003e. No matter how comprehensive a program may be, you and your coworkers will ultimately determine the success of our established procedures.\u0026nbsp;\u003c/p\u003e\u003cp\u003eAnd we are here to help you along the way! This Handbook is your primary resource for initial information about your role, and will direct you to other sources of help and support.\u003c/p\u003e\u003cp\u003eHere are the steps you should take to get started:\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eComplete the paperwork\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIf you have not already, make sure that your \u003ca href=\"/learn/isso-appointment-letter\"\u003e\u003cstrong\u003eISSO Appointment Letter\u003c/strong\u003e\u003c/a\u003e is completed and submitted to your Cyber Risk Advisor (CRA) by your Business Owner (BO). The Appointment Letter is intended to formally nominate you as an ISSO. It also gives you a wealth of information about your duties and responsibilities. It also contains the qualifications and training to which you should aspire. This document may be your first communication with your CRA — the first of many conversations.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf you need a copy of the ISSO Appointment Letter template, contact the ISSO Support Team: \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eComplete ISSO onboarding\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO Support team in ISPG can help get you started. You should ask for an initial meeting with the team to orient you to your new role and next steps. \u0026nbsp; You should also reach out to your CRA, who may wish to meet on a regular basis initially, especially if your system has an important near-term milestone. If your BO did not set this up for you, you can do it yourself by sending a note to \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e. It is helpful to put the word “Onboarding” in the subject line.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKnow your systems\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eMake sure that in your conversation with your Business Owner, you understand whether you are going to be the primary ISSO (or the only ISSO), or if you are going to be an assistant. Do you know where your system is located? When does the Authority to Operate (ATO) expire? Are you working on a new system? The more you know at the beginning, the easier it will be to prioritize and to work with your integrated team. If you have questions about any of this, reach out to the ISSO Support Team (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMeet your team\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIn addition to your BO and your CRA, there are others that you should get to know. We recommend that you reach out to them. We also recommend face to face meetings, at least initially. Some others you should get to know include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eOther ISSOs in your component, if applicable\u003c/li\u003e\u003cli\u003eYour system’s Technical Lead\u003c/li\u003e\u003cli\u003eWhen appropriate, your system’s contractor security support\u003c/li\u003e\u003cli\u003eThe ISSO Support Team (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAssess your skills with the ISSO Score Card\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eISSOs come from many backgrounds, both technical and non-technical. Even new ISSOs with a technical background may not be familiar with the “CMS way” of operating. While you will be busy with your new role, you should take some initial time to get a better awareness of your capabilities to be a CMS ISSO through some focused initial training.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWe’ve made it easy to figure out what training you should prioritize using a self-assessment tool: the \u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eISSO Score Card.\u003c/a\u003e Every ISSO is encouraged to take this assessment regularly as their knowledge expands. The ISSO Score Card is:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eConfidential\u003c/strong\u003e - only you will see the results\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eQuick\u003c/strong\u003e - only taking 10-15 minutes to complete\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eGeared to ISSO duties\u003c/strong\u003e - taken directly from CMS policies and requirements\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePersonalized\u003c/strong\u003e - you’ll get a customized report to help you make a training plan\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eEasy\u003c/strong\u003e - using a simple online web interface\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eGo to the ISSO Score Card\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eSign up for training\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAs an ISSO, it is vital that you understand security and privacy fundamentals and how they are applied at CMS. Regardless of your prior level of experience, you will need to know the CMS-specific workflows and governance. There is a wealth of training available to you, both for getting started and deepening your knowledge.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eWondering where to start\u003c/strong\u003e? Here’s a simple checklist to make sure you complete the essential training that will start you on the road to success:\u003c/p\u003e\u003cul\u003e\u003cli\u003eFigure out what you need to know (or brush up on) using the \u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eISSO Score Card\u003c/a\u003e. Use the results to sign up for training that is customized to your level.\u003c/li\u003e\u003cli\u003eLearn about 6 key job functions of ISSOs using the \u003ca href=\"https://www.cms.gov/cbt/login/default.aspx\"\u003evideo training series from CMS\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eSign up for CFACTS training – it’s worth the 2-day time investment to get a solid grasp on this essential tool for the ISSO’s daily work. (This is available in the CMS Computer Based Training platform).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFinally, to build upon the checklist above, we have provided a list of Basic, Intermediate, and Advanced ISSO training courses that are free for you to take. See the Training section of this Handbook for details.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eGet a mentor\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOptionally, you can join the \u003ca href=\"/learn/isso-mentorship-program\"\u003e\u003cstrong\u003eISSO Mentorship Program\u003c/strong\u003e\u003c/a\u003e to be paired with an experienced ISSO. Once paired, you should work together to develop a cadence for meeting and knowledge sharing. This allows you to gain confidence faster and get hands-on support. Learn more about the ISSO Mentorship Program here.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eJoin the community\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe cybersecurity community at CMS is alive and growing. There are all kinds of ways that you can get involved, get an idea of what’s going on at CMS, and learn how it affects you. Attend the CMS Cybersecurity Community Forum, read the ISSO Journal, and look for ISPG-sponsored security and privacy activities.\u003c/p\u003e\u003cp\u003eFinally, if you have any questions along the way, just ask. Your job is very important to the success of CMS programs, and everyone at ISPG is here to support you!\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eGoals for your first year\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eBy the end of your first year as an ISSO, it should be your goal to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eLearn the security planning and administrative security procedures for systems that process sensitive information such as PHI, PII, FTI, and classified and national intelligence data\u003c/li\u003e\u003cli\u003eUnderstand the implementation and enforcement of CMS’ Information System Security and Privacy policies and practices\u0026nbsp;\u003c/li\u003e\u003cli\u003eKnow the concerns and requirements that determine the administration and management of physical, system, and data access controls based on the sensitivity of the data processed and the corresponding authorization requirements\u003c/li\u003e\u003cli\u003eLearn the identification, analysis, assessment and evaluation of information system threats and vulnerabilities and their impact on their component’s critical information infrastructures\u003c/li\u003e\u003cli\u003eBe able to identify management, technical, personnel, operational and physical security controls\u003c/li\u003e\u003cli\u003eUnderstand any additional critical areas of knowledge related to your system\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eRole and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eISSOs maintain a strong security and privacy posture for their assigned system(s) in the following high-level ways:\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eServe as principal advisor\u003c/strong\u003e to the System Owner (SO), Business Owner (BO), and the Chief Information Security Officer (CISO) on all system security and privacy matters\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMaintain system authorization \u003c/strong\u003eby following the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-risk-management-framework-rmf\"\u003eNIST Risk Management Framework\u003c/a\u003e to select, implement, document, test, and maintain the security and privacy controls required to authorize and operate information systems within CMS’s risk tolerance throughout the \u003ca href=\"https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/tlc\"\u003eTarget Life Cycle\u003c/a\u003e (TLC)\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMaintain security and privacy operations\u003c/strong\u003e capabilities sufficient to identify, detect, protect, respond, and recover from security incidents (as per the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-cybersecurity-framework-csf\"\u003eNIST Cybersecurity Framework\u003c/a\u003e)\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMeet federal reporting requirements\u003c/strong\u003e for information security and privacy, including documenting and mitigating weaknesses and reporting incidents and breaches\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eManage privacy requirements\u003c/strong\u003e by working collaboratively with Data Guardians and Privacy Advisors\u003c/p\u003e\u003cp\u003eThe official role and specific responsibilities for ISSOs are outlined in detail by the CMS Information Security and Privacy Policy (IS2P2), which is based upon the related policy document from HHS (IS2P). The following list is based on those policy documents and includes some key duties for ISSOs:\u003c/p\u003e\u003cul\u003e\u003cli\u003eComplete the security categorization for the FISMA system using the CFACTS tool\u003c/li\u003e\u003cli\u003eComplete and maintain the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan\u003c/a\u003e using the CFACTS tool\u003c/li\u003e\u003cli\u003eEnsure \u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e – and \u003ca href=\"/learn/penetration-testing\"\u003ePenetration Tests\u003c/a\u003e have been scheduled and completed in a timely manner\u003c/li\u003e\u003cli\u003eDevelop, document and maintain an inventory of hardware and software components within the FISMA system’s authorization boundary\u003c/li\u003e\u003cli\u003eCoordinate the development of a \u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan\u003c/a\u003e and ensure the plan is tested and maintained accordingly\u003c/li\u003e\u003cli\u003eMaintain primary responsibility for the actions and activities associated with the FISMA system receiving and maintaining an \u003ca href=\"/learn/authorization-operate-ato\"\u003eAuthority to Operate (ATO)\u003c/a\u003e\u003c/li\u003e\u003cli\u003eCoordinate with the ISO, BO, and CRA to manage information security and privacy risk\u003c/li\u003e\u003cli\u003eMonitor and update all POA\u0026amp;Ms in accordance with current requirements and instruction\u003c/li\u003e\u003cli\u003eSubmit recommendations to the CRA for system configuration deviations from the required baseline\u003c/li\u003e\u003cli\u003eIdentify the information security and privacy controls provided by the applicable infrastructure that are common controls for information systems;\u003c/li\u003e\u003cli\u003eCoordinate with the ISO, BO, and CRA to meet all collection, creation, use, dissemination, retention, and maintenance requirements for sensitive information in accordance with the Privacy Act, E-Government Act, and all other applicable guidance\u003c/li\u003e\u003cli\u003eCoordinate with the BO, Contracting Officer, ISO, and CISO to ensure that all requirements specified by the \u003ca href=\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eARS 5.1\u003c/a\u003e and the \u003ca href=\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\"\u003eRMH\u003c/a\u003e are implemented and enforced for applicable information and information systems\u003c/li\u003e\u003cli\u003eReport and manage IT Security and Privacy Incidents in accordance to the RMH and other applicable federal guidance\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eTypes of ISSO roles\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe specific type of ISSO role assigned to a system will depend on the needs of the system and the available personnel. The descriptions below are taken from the CMS Information Security and Privacy Policy (IS2P2).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrimary Information System Security Officer (P-ISSO)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS P-ISSO may be either a federal government employee or a contractor and must fulfill all of the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.24, System Security and System Privacy Officers. ISSO must ensure the duties of the Security Control Assessor and Contingency Planning Coordinator are completed as described in the IS2P Sections 7.26 and 7.30.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecondary Information System Security Officer (S-ISSO)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS S-ISSO may be either a federal government employee or a contractor identified in the IS2P Section 7.25, ISSO Designated Representative / Security Steward and must assist the P-ISSO.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInformation System Security Officer Contractor Support (ISSOCS)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe ISSOCS is a contractor-only role that assists and supports the P-ISSO and S-ISSO roles in fulfillment of their CMS cybersecurity duties.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity or Privacy Control Assessor\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Security or Privacy Control Assessor role may be performed by an ISSO. The CMS Security or Privacy Control Assessor must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.23.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eContingency Planning Coordinator\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Contingency Planning Coordinator may either be a federal government employee or a contractor. The role may also be performed by an ISSO. The CMS Contingency Planning Coordinator must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.30.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eISSO checklist\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThis section provides a list of specific tasks an ISSO should perform periodically. The timelines listed for each task are general guidelines, which may vary depending on the Component guidance or system circumstances. This list isn’t comprehensive, but serves as a quick reference to help you plan your work. You may choose to make a spreadsheet for yourself to keep track of recurring tasks and due dates.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eWeekly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview audit logs\u003c/li\u003e\u003cli\u003eRoutinely evaluate risk posture based upon change requests\u003c/li\u003e\u003cli\u003eEnsure data is backed up\u003c/li\u003e\u003cli\u003eCheck status of any \u003ca href=\"/learn/plan-action-and-milestones-poam\"\u003ePlan of Action and Milestones (POA\u0026amp;M)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eMonthly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview / deactivate unused accounts\u003c/li\u003e\u003cli\u003eEnsure all POA\u0026amp;Ms with Open or Delay status are annotated with current status\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eQuarterly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsure that all data in CFACTS is current and accurate one week before the end of the quarter (CMS submits a quarterly FISMA report to OMB based on this data)\u003c/li\u003e\u003cli\u003eEnsure the completion of internal vulnerability scans\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eAnnually\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview and update all \u003cstrong\u003eSecurity Authorization Process documentation\u003c/strong\u003e, such as those listed below. Remember that most of these require months of effort to complete, so you must be working on them well in advance.\u003cul\u003e\u003cli\u003e\u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eInformation System Risk Assessment (ISRA)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan (CP)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePrivacy Impact Assessment (PIA)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e Note: Updating security control implementation is a necessary first step to updating the SSPP. When updating any documents, ensure the old copy is retained.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eEnsure that all system users and people with significant security responsibilities (e.g., ISSOs) receive their required annual awareness training\u003c/li\u003e\u003cli\u003eConduct a Contingency Plan Test with associated training, after-action, and updated POA\u0026amp;Ms as necessary. Ensure that the Business Owner certifies (signs) any updated CP document.\u003c/li\u003e\u003cli\u003eReview the Privacy Impact Assessment (PIA) for your system(s) and update as appropriate\u003c/li\u003e\u003cli\u003eEnsure vulnerability assessments are completed at least annually, or when significant changes are made to the system\u003c/li\u003e\u003cli\u003eReview and validate user access rights\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOngoing\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eContinual security control assessment to ensure no risks are present\u003c/li\u003e\u003cli\u003eContinual work on tests and assessments (as needed) such as:\u003cul\u003e\u003cli\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/li\u003e\u003cli\u003ePenetration Testing\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eContinual updating of the \u003cstrong\u003eSecurity Authorization Process documentation\u003c/strong\u003e (see list in the section above). All of these should be updated as changes occur, and all require an annual review and update.\u003c/li\u003e\u003cli\u003eComplete incident response reports (as required)\u003c/li\u003e\u003cli\u003eATO updates (as required)\u003c/li\u003e\u003cli\u003eRespond to any CCIC monitoring alerts (as required)\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eISSO activities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eUse this section to learn in-depth about the activities you must understand and perform as an ISSO – from the very beginning of your system’s development. These activities support the CMS \u003ca href=\"https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/tlc\"\u003eTarget Life Cycle\u003c/a\u003e (TLC), which is the framework that standardizes how IT systems are built, maintained, and retired at CMS. The ISSO activities also support the Risk Management Framework (RMF) from NIST, which helps organizations integrate security considerations into their software development processes.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eConduct a Security Impact Analysis (SIA)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe \u003ca href=\"/learn/security-impact-analysis-sia\"\u003eSecurity Impact Analysis\u003c/a\u003e\u0026nbsp;is the process that you will use initially for your new system and \u003cstrong\u003eevery time\u003c/strong\u003e a new change to the system is proposed. When you have completed this process, you will be able to provide substantive recommendations to your Business Owner on the impact of any proposed change(s). The impact may be small, or it may rise to the level of a new ATO process.\u003c/p\u003e\u003cp\u003eNote:\u0026nbsp; SIAs are frequently thought of as documents.\u0026nbsp; Remember that \u003cstrong\u003eSIA is a process\u003c/strong\u003e.\u0026nbsp; Based on the complexity and extent of the process, a completed form may help better describe the security impact, as well as necessary actions to take.\u0026nbsp; The actual CMS/FISMA requirement noted in ARS 5.1 Control CM-4 requires “Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) to conduct security impact analyses.”\u0026nbsp; It is up to you and your Business Owner/organization to determine the level to which you document your analysis.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-impact-analysis-sia\"\u003eLearn about Security Impact Assessment (SIA)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCategorize your FISMA system\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eYour FISMA system has different security controls based on the sensitivity of the information contained in or processed by your system. Categorization takes place within CFACTS.\u0026nbsp; You enter the appropriate area and select the type of information that will be processed.\u0026nbsp; The system categorization will be suggested automatically and noted as “Low”, “Moderate”, or “High”.\u0026nbsp; If necessary, the categorization may be manually overridden; your CRA will have to help with this.\u0026nbsp; In practice this seldom happens.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis system categorization will have a variety of uses.\u0026nbsp; Most importantly, you will need to have this information to determine which controls to allocate for your system.\u003c/p\u003e\u003cp\u003eNote: Although this process sounds like it will only be done once for your FISMA system, \u003cstrong\u003eyou may have to repeat it\u003c/strong\u003e if a proposed change includes access or storage of different types of data. \u0026nbsp; Your completed SIA will guide your actions.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/federal-information-security-modernization-act-fisma#perform-system-risk-categorization\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eLearn more about system categorization here\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/posts/watch-and-learn-system-categorization-cfacts\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eSee how to categorize your system in CFACTS\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eDetermine the Authorization Boundary\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAnother major initial task is to determine the system’s \u003cstrong\u003eAuthorization Boundary\u003c/strong\u003e. The NIST definition of authorization boundary is: “All components of an information system to be authorized for operation by an authorizing official and excludes separately authorized systems, to which the information system is connected”.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eOne practical way of determining the system’s authorization boundary is to ask whether a particular component can be changed by one’s system team, or if another team has to make updates or changes.\u0026nbsp; If your team can make the change or configuration, chances are that the component falls within your authorization boundary. As with system categorization, the authorization boundary is usually determined at the outset of system development. It may expand or contract based on changes to the system over its lifecycle.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBe aware of High Value Assets (HVAs)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe HHS HVA Program Policy defines HVAs as: “Assets, federal information systems, information, and data for which an unauthorized access, use, disclosure, disruption, modification, or destruction could cause a significant impact to the United States’ national security interests, foreign relations, economy, or to the public confidence, civil liberties, or public health and safety of the American people.”\u003c/p\u003e\u003cp\u003eThe practical impact of this program is that, if your FISMA system is defined as an HVA, it will face additional security requirements from DHS and HHS, which may impact the continuity operations and assessments of the system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAllocate controls\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOnce a system has been categorized, the ISSO has the information necessary to select controls, or allocate them.\u0026nbsp; The process is largely automatic, and is well-described in the CMS Risk Management Handbook (RMH) Chapter 12: Security and Privacy Planning. Selected controls are allocated for Low, Moderate, or High systems based on system categorization. The mechanics are described very well in the CFACTS User Manual, so that should be your primary reference point on allocating controls. Some general control types include:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSystem-specific controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThese are controls that your system “owns”.\u0026nbsp; If you are running on hardware that you are responsible for, there are system-specific controls for it.\u0026nbsp; If your system is an application, or Major Application, the system-specific controls are those controls that your developers and administrators configure and maintain.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInherited controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIn many cases your system uses components provided by other FISMA systems. In the above example about hardware, what if your system is housed on hardware administered by others? This is not just a possibility – in most cases major applications run within a separate data center. Certainly this is the case for systems housed in the AWS Cloud. In these instances, the data center (or other entity) that houses your system will most likely take care of some of the controls for your system – in which case your system will be able to “inherit” controls.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf the providing system completely takes care of a control, it is called a \u003cstrong\u003ecommon, or fully inherited\u003c/strong\u003e control. If the providing system takes care of part of a control, and relies on your system to take care of the rest of the control, it is called a \u003cstrong\u003ehybrid\u003c/strong\u003e control. (The CFACTS User Manual has additional information on how to inherit a control.)\u003c/p\u003e\u003cp\u003eUnderstanding which controls your team must address and which controls are available through full or partial inheritance will help you understand how to document your security control compliance (which is the next step in the cycle).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSupplemental controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSupplemental controls (previously referred to as non-mandatory controls in ARS 3.1) can be added to a system as necessary, and are not included in baseline control allocation. They should be reviewed and added as appropriate for your system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eImplement security controls\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIt is your responsibility as your system’s security and privacy Subject Matter Expert to make sure that your Business Owner, system developers, and system administrators understand the controls that must be in place for your system to be “secure” to CMS standards.\u0026nbsp; Once these controls have been implemented, \u003cstrong\u003ethey need to be documented within CFACTS\u003c/strong\u003e.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote:\u0026nbsp; All security controls that have been allocated for your system \u003cstrong\u003emust have some comment\u003c/strong\u003e. \u0026nbsp; Even fully inherited controls should have a notation that the control is fully inherited.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDevelop system documentation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eProminent documents are important to understanding the security posture of your FISMA system.\u0026nbsp; CFACTS can help with this process by automatically generating some of the documents, such as the System Security Plan. Other documents are found within CFACTS, such as System Categorization. Others, such as the Information System Risk Assessment (ISRA) must be completed using CMS-approved templates. Finally, others may either use a CMS template or a locally generated document such as the Security Impact Assessment (SIA).\u003c/p\u003e\u003cp\u003eNote:\u003cstrong\u003e Make sure that all CFACTS entries, including all security controls, are accurate and complete at all times.\u0026nbsp;\u003c/strong\u003e This will ensure that CFACTS-generated documents are accurate.\u003c/p\u003e\u003cp\u003eItems for the system documentation include:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSystem Security and Privacy Plan (SSPP)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSSPP\u003c/a\u003e is the key document associated with the FISMA system security. It should provide an accurate, detailed description of the FISMA system itself, security requirements, and those controls that are actually in place to protect the system. This document is generated by CFACTS.\u003c/p\u003e\u003cp\u003eTip: It is a best practice to maintain older copies of SSPPs as new versions are generated. Do not overwrite old SSPPs; you never can tell when you might need to refer to an older version.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eLearn more about System Security and Privacy Plan (SSPP)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInformation System Risk Assessment (ISRA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eISRA\u003c/a\u003e details the business and technical risks associated with a FISMA system.\u0026nbsp; It shares high-level information from CFACTS, as well as specific risks noted and how critical they are.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eLearn more about Information System Risk Assessment (ISRA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrivacy Impact Assessment (PIA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePIA\u003c/a\u003e is not simply a compliance step – it guides the full analysis of a system for privacy risks and controls. A PIA is a process for assessing whether appropriate privacy policies, procedures, business practices, and security controls are implemented to ensure compliance with federal privacy regulations. PIAs are published on HHS.gov and go through a three-year review process.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003eLearn more about Privacy Impact Assessment (PIA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eThird-Party Websites and Applications\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"https://www.osec.doc.gov/opog/privacy/Memorandums/OMB_M-10-23.pdf\"\u003eOffice of Management and Budget Memorandum 10-23\u003c/a\u003e, Guidance for Agency Use of Third-Party Websites and Applications, requires that agencies assess their uses of third-party websites and applications to ensure that the use protects privacy. The mechanism by which agencies perform this assessment is a privacy impact assessment (PIA).\u0026nbsp;\u003c/p\u003e\u003cp\u003eIn accordance with HHS policy, operating divisions (OPDIVs) are responsible for completing and maintaining PIAs for all third-party websites and applications in use. Upon completion of each assessment, agencies are required to make the PIAs publicly available. The CMS Third-Party Websites and Applications (TPWA) Privacy Impact Assessments for each individual OPDIV system can be \u003ca href=\"https://www.hhs.gov/pia/index.html#Third-Party\"\u003eaccessed here on the HHS website\u003c/a\u003e. CMS implementation specifications are included in the CMS Acceptable Risk Safeguards (ARS 5.1).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrivacy Threshold Analysis\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eA Privacy Threshold Analysis (PTA) is a PIA for a system that does not contain PII or only contains HHS employee information. PTAs remain internal to HHS and do not have to go through the three-year review process. A PTA may be updated based on a major change to the system. It is also possible that change to a system could result in a PTA then meeting the threshold to be a PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eConduct Contingency Planning (CP)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://dkanreserve.prod.acquia-sites.com/policy-guidance/risk-management-handbook-chapter-6-contingency-planning-cp\"\u003eContingency Planning\u003c/a\u003e\u0026nbsp;provides instructions, disaster declaration criteria, and procedures to recover information systems and associated services after a disruption. It involves cooperation with your Business Owner, your data center or hosting facility, and senior CMS leadership. (See CMS Risk Management Handbook Chapter 6: Contingency Planning).\u003c/p\u003e\u003cp\u003eAs the ISSO, you will coordinate efforts with your Business Owner to determine the business criticality of key processes. This effort will result in a Business Impact Analysis (BIA) which, in turn, serves as the primary requirement document for determining key recovery metrics including the Recovery Point Objective (RPO), Recovery Time Objective (RTO), Maximum Tolerable Downtime (MTD), and Work Recovery Time (WRT).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe goal is to ensure that there are plans in place to restore business functionality within the Maximum Tolerable Downtime.\u0026nbsp; Note that this may involve restoring the system as originally constructed, moving to alternate processing facilities, or even moving to alternate processing methods.\u0026nbsp;\u003c/p\u003e\u003cp\u003eHere are the key steps and documents involved in Contingency Planning:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCreate Contingency Plan (CP) document\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CP Plan is a single document that contains:\u003c/p\u003e\u003cul\u003e\u003cli\u003eKey recovery metrics for your FISMA system\u003c/li\u003e\u003cli\u003ePre-defined descriptions of conditions that constitute a need for action\u003c/li\u003e\u003cli\u003ePre-defined actions based on the severity of an identified incident\u003c/li\u003e\u003cli\u003eKey staff, contact information, and specific duties for each person\u003c/li\u003e\u003cli\u003eItem-level understanding of all of the hardware and software components of the FISMA system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIt’s important to keep in mind:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CP must be attested to (signed) by the FISMA System Owner annually.\u003c/li\u003e\u003cli\u003eAll of the information necessary for the conducting of a contingency plan must be in the CP.\u0026nbsp; There should be no references to offline personnel lists, contact information, system information, etc.\u0026nbsp;\u003c/li\u003e\u003cli\u003eAll identified Key Personnel must have access to their own copy of the CP in a secure location that is accessible in the event that the FISMA system is unavailable.\u003c/li\u003e\u003cli\u003eThe Contingency Plan, above all FISMA system documentation, must remain current.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eConduct Contingency Plan (CP) Exercise\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CP must be exercised (tested) at least once every 365 days. This is commonly referred to as the “Tabletop Exercise”, but a tabletop exercise is only one (the easiest) way to test the CP. An exercise plan must be prepared and followed during the execution of the test. All staff who participate in an actual CP event must be available for the exercise.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote: \u003cstrong\u003eKey staff members must be trained annually in their contingency responsibilities.\u003c/strong\u003e It is best to perform this training immediately prior to the exercise. Training in this way refreshes individuals’ memories and ensures their availability for the test.\u003c/p\u003e\u003cp\u003e\u003cem\u003eTip: If your FISMA system is involved in an outage that causes you to exercise the CP Plan, you should consider documenting this event as an exercise of your CP Plan.\u003c/em\u003e\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/contingency-plan\"\u003eLearn more about Contingency Plan testing\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eGet after action report\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAfter the exercise is conducted, an after action report must be generated to describe the test and highlight specific deficiencies that must be corrected.\u0026nbsp; These deficiencies may be easily correctable, or may result in POA\u0026amp;Ms.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eAchieve Contingency Plan (CP) re-certification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAfter any corrections have been made, the updated Contingency Plan must be re-certified by the System Owner. Make sure that all key staff members receive updated CP documents that they have access to (\u003cstrong\u003eeven away from the office or after hours\u003c/strong\u003e). Destroy (or return) older copies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAssess security controls for your system(s)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems are required to undergo assessments of risk and security/privacy control compliance before they are given Authorization to Operate (ATO). The assessment and authorization process protects the security and privacy posture of CMS systems throughout the system development lifecycle.\u0026nbsp;\u003c/p\u003e\u003cp\u003eAssessments of risk and/or control compliance are conducted:\u003c/p\u003e\u003cul\u003e\u003cli\u003eWhen a new system is ready to be placed into an operational state\u003c/li\u003e\u003cli\u003eWhen a significant change has been made to an existing system\u003c/li\u003e\u003cli\u003eAnnually, if a system follows a FISMA 1/3 assessment schedule\u003c/li\u003e\u003cli\u003eAd hoc when requested or otherwise required\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCurrently there are two main types of controls assessments – SCA and ACT.\u0026nbsp; Your component will dictate which type of assessment your system undergoes.\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote: Whichever one your system uses, make sure to schedule your assessment \u003cstrong\u003eas soon as possible\u003c/strong\u003e. When the assessment is complete, make sure all documentation is complete and housed in CFACTS appropriately.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity Controls Assessment (SCA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis is a detailed evaluation of the controls protecting an information system.\u0026nbsp; The security controls assessment determines the extent to which controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-controls-assessment-sca\"\u003eLearn more about Security Controls Assessment (SCA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCybersecurity and Risk Assessment Program (CSRAP) (Formally Adaptive Capabilities Testing (ACT))\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCSRAP is a security and risk assessment for FISMA systems at CMS. CSRAP assesses a system's security capabilities to ensure that it operates as intended and meets the security requirements for the information system. CSRAP is a critical component of the \u003ca href=\"https://cybergeek.cms.gov/learn/authorization-operate-ato\"\u003eAuthorization to Operate (ATO)\u003c/a\u003e process and is used to determine the overall system security and privacy posture throughout the system development life cycle (SDLC). For detailed information about CSRAP, see \u003ca href=\"https://confluenceent.cms.gov/download/attachments/214794255/CSRAP%20Assessment%20Handbook%20v3.1.pdf?version=1\u0026amp;modificationDate=1711993052415\u0026amp;api=v2\"\u003eCybersecurity and Risk Assessment Program Handbook\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePenetration testing\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePenetration testing is performed on information systems or individual system components to identify vulnerabilities that could be exploited by bad actors. It is used to validate vulnerabilities or determine the degree of resistance that organizational information systems have to risk within a set of specified constraints (e.g., time, resources, and/or skills).\u0026nbsp;\u003c/p\u003e\u003cp\u003ePenetration testing attempts to duplicate the actions of internal and external bad actors in carrying out hostile cyber-attacks against the organization and allows a more in-depth analysis. It can be conducted on the hardware, software, or firmware components of an information system and can exercise both physical and technical security controls.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePenetration testing is performed on all High Value Assets (HVA) information systems within CMS at a frequency of every 365 days or when there has been a significant change to the system.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIt is considered to be part of the group of assessments required for CMS systems, and its results are recorded in CFACTS similarly to the controls assessments (SCA and/or ACT).\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/penetration-testing\"\u003eLearn more about penetration testing\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity Assessment Report (SAR) and CAAT file\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eFor all assessments, a final Security Assessment Report (SAR) chronicles the results of the assessment. The \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eRisk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization\u003c/a\u003e states:\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cem\u003eAt the completion of a security controls assessment, the independent assessor completes a CMS Assessment and Audit Tracking (CAAT) spreadsheet. The CAAT spreadsheet is utilized for all CMS audits, assessments and penetration testing vulnerabilities. The completed CAAT spreadsheet is emailed to the CMS CISO mailbox at \u003c/em\u003e\u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003e\u003cem\u003eCISO@cms.hhs.gov\u003c/em\u003e\u003c/a\u003e\u003cem\u003e for upload into the CFACTS tool. Once uploaded into CFACTS, the weaknesses are automatically generated for all items with a status of “other than satisfied”. The ISSO for the associated information system receives an automated email notification from the CFACTS tool identifying a new weakness. The ISSO has 30 days to create a POA\u0026amp;M within CFACTS.\u003c/em\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManage Plan of Action and Milestones (POA\u0026amp;M)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe POA\u0026amp;M is a remedial action plan (the process of accepting or resolving a risk) which helps the agency to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIdentify and assess information system security and privacy weaknesses\u003c/li\u003e\u003cli\u003eSet priorities about how to mitigate weaknesses using available resources\u003c/li\u003e\u003cli\u003eMonitor and report progress toward mitigating the weaknesses\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eYou – as the ISSO – are responsible for opening, maintaining / updating, and closing POA\u0026amp;Ms on a continual basis to ensure the maximum level of information security for system(s) entrusted to your care.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/plan-action-and-milestones-poam\"\u003eLearn more about Plan of Action \u0026amp; Milestones (POA\u0026amp;M)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthorize the system\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eSystem authorization is the formal decision by senior officials to allow a CMS information system to operate. Commonly known as Authorization to Operate (ATO), this is the culmination of all the tests, assessments, remediation, documentation, and other activities that the ISSO and others on the portfolio team have done to ensure information security for the system.\u003c/p\u003e\u003cp\u003eIn formal terms, authorization is described in the CMS Risk Management Handbook Chapter 4: Security Assessment and Authorization:\u003c/p\u003e\u003cp\u003e\u003cem\u003eSecurity authorizations are official management decisions that are conveyed through authorization decision documents by senior organizational officials or executives (i.e., authorizing officials) to authorize operation of information systems to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon security controls. The CIO serves as the authorizing official for CMS. The CIO is responsible for making an overall determination of risk and authorizing CMS information systems for operation, if it is determined that the associated risks are acceptable. An ATO memo is signed by the CIO giving the System Owner/BO formal authority to operate a CMS information system.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThere are three NIST document requirements for an ATO “package” and six more that are specific to CMS.\u0026nbsp; The documents include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eSystem Security and Privacy Plan (SSPP)\u003c/li\u003e\u003cli\u003eSecurity Assessment (Final) Report (SAR)\u003c/li\u003e\u003cli\u003ePlans of Action and Milestones (POA\u0026amp;M)\u003c/li\u003e\u003cli\u003eContingency Plan (CP)\u003c/li\u003e\u003cli\u003eCP Testing Plan\u003c/li\u003e\u003cli\u003eCP Test After Action Report\u003c/li\u003e\u003cli\u003eInformation System Risk Assessment (ISRA)\u003c/li\u003e\u003cli\u003ePrivacy Impact Assessment (PIA)\u003c/li\u003e\u003cli\u003eInterconnection Security Agreement (ISA) – as applicable\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eGetting these documents together and conducting all necessary steps can be a long process – so \u003cstrong\u003eyou should start working on your ATO as early as possible\u003c/strong\u003e to ensure timely completion.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/authorization-operate-ato\"\u003eLearn more about System Authorization\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eContinuous monitoring\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eContinuous monitoring is the practice of using modern tools and technology to continuously check systems for vulnerabilities and risks. Rather than thinking of getting an ATO as having “achieved” compliance, continuous monitoring allows us to observe and track evolving risks over time. Security is never “done”.\u003c/p\u003e\u003cp\u003eContinuous monitoring is a growing program at CMS. As an ISSO, you will work closely with the CMS Cybersecurity Integration Center (CCIC) to ensure that your system is appropriately monitored.\u0026nbsp; CCIC ensures oversight of information security and privacy, including Security Information Event Management, for each FISMA system operating by or on behalf of CMS.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe CCIC delivers various agency-wide security services.\u0026nbsp; These services include \u003ca href=\"/learn/continuous-diagnostics-and-mitigation-cdm\"\u003eContinuous Diagnostics and Mitigation (CDM)\u003c/a\u003e as well as security engineering, incident management, forensics and malware analysis, information sharing, cyber threat intelligence, penetration testing, and software assurance.\u003c/p\u003e\u003cp\u003eMore information about continuous monitoring can be found in the \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eCMS Risk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManage security incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAlong the way, a system entrusted to your care might have a security or privacy incident or breach. Anytime there is a violation of computer security policies, acceptable use policies, or standard security practices at CMS, it is considered an\u003cstrong\u003e incident\u003c/strong\u003e. If an incident involves the loss of control or unauthorized disclosure of Personally Identifiable Information (PII), then the incident is considered a \u003cstrong\u003ebreach\u003c/strong\u003e.\u003c/p\u003e\u003cp\u003eKnown or suspected security or privacy incidents involving CMS information or information systems \u003cstrong\u003emust be reported immediately\u003c/strong\u003e to the CMS IT Service Desk:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePhone: 410-786-2580 or 1-800-562-1963\u003c/li\u003e\u003cli\u003eEmail: \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e.\u0026nbsp;\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eYou as the ISSO should be apprised of the situation as soon as possible (if you’re not the one who initially reported the incident). You will work with the Incident Management Team (IMT) and others involved with your system to manage and report the incident and mitigate any resulting harm. More details can be found in the CMS Risk Management Handbook (RMH) Chapter 8: Incident Response.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eISSO toolkit\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis section contains links to documents you will access often in your daily activities, and resources to support your work as an ISSO. You should become familiar with the purpose and usage of each.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDocuments\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCMS Acceptable Risk Safeguards (ARS 5.1)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Information Security Acceptable Risk Safeguards (ARS 5.1) defines information security and privacy control requirements and includes additional, detailed policy traceability statements within each control description. The ARS 5.1 provides guidance on customizing (tailoring) controls and enhancements for specific types of missions/business functions, technologies, or environments of operation. Users of the ARS 5.1 may tailor specific mandatory controls as well as most of the non-mandatory and unselected controls.\u003c/p\u003e\u003cp\u003eThe goal of the ARS 5.1 is to define a baseline of minimum information security and privacy assurance controls. The controls are based on both internal CMS governance documents and laws, regulations, and other authorities created by institutions external to CMS. Protecting and ensuring the confidentiality, integrity, and availability for all of CMS’ information and information systems is the primary purpose of the information security and privacy assurance program. The ARS 5.1 complies with the CMS IS2P2 by providing a defense-in-depth security structure along with a least-privilege, need-to-know basis for all information access.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cybergeek.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eLearn more about ARS 5.1\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Information Security and Privacy Policy (IS2P2)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis policy defines the framework under which CMS protects and controls access to CMS information and information systems. It provides direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems; systems maintained on behalf of CMS; and other collections of information to assure the confidentiality, integrity, and availability of CMS information and systems.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eAlong with the Acceptable Risk Safeguards (ARS 5.1), the IS2P2 stands as one of the core reference sources for cybersecurity policies and practices at CMS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eGo to the IS2P2\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Risk Management Handbooks\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis series of handbooks is designed to help ISSOs understand and address the many CMS security and privacy requirements developed to protect their system(s). The RMH chapters are generally aligned to provide specific guidance and recommendations for specific ARS 5.1 Control Families. (For example, \u003cstrong\u003eRMH Chapter 6: Contingency Planning\u003c/strong\u003e addresses the ARS 5.1 controls in the \u003cstrong\u003eCP Family\u003c/strong\u003e.) As you work through your ARS 5.1 controls, you should have the appropriate RMH handy.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\"\u003eLearn more about the CMS Risk Management Handbook (RMH)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTools and resources\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCFACTS\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS FISMA Controls Tracking System (CFACTS) is the system used by CMS as a repository for managing the security and privacy requirements of its information systems. It provides a common foundation to manage policies, controls, risks, assessments, and deficiencies across the CMS enterprise. You will use it for tracking your tasks associated with system authorization, risk remediation, and more.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cfacts3.cms.cmsnet/apps/ArcherApp/Home.aspx#home\"\u003eGo to CFACTS\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003cp\u003eA user manual is produced by the team that administers CFACTS and gives a guided tour through all activities in CFACTS. Although it is not a primer in risk management, many activities and concepts can be understood implicitly through their description in the User Manual and implementation in CFACTS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cfacts3.cms.cmsnet/apps/ArcherApp/Home.aspx\"\u003eGo to CFACTS user manual\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISPG website (CyberGeek)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe Information Security and Privacy Group (ISPG) provides the “CyberGeek” website as a one-stop shop for all security and privacy related information at CMS – including dedicated resource pages for ISSOs and other roles. This is a new site, and more information will become available as it grows.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://security.cms.gov/\"\u003eGo to ISPG website (CyberGeek)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Slack\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSlack is an application that allows for fast and easy communication among all CMS employees and contractors. Spaces called channels allow for focused communication which will keep you organized and informed during your daily routine. Below is a list of Slack channels that will help you on your journey to becoming a fully independent ISSO:\u003c/p\u003e\u003cul\u003e\u003cli\u003e#ars-feedback\u003c/li\u003e\u003cli\u003e#cfacts_community\u003c/li\u003e\u003cli\u003e#cisab\u003c/li\u003e\u003cli\u003e#cms-isso\u003c/li\u003e\u003cli\u003e#cyber-risk-management\u003c/li\u003e\u003cli\u003e#ispg-all\u003c/li\u003e\u003cli\u003e#isso-as-a-service\u003c/li\u003e\u003cli\u003e#security_community\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAcronyms\u003c/h4\u003e\u003cp\u003eLike most other parts of government, the security and privacy world at CMS is full of acronyms. ISPG maintains a list of acronyms so you can easily look up unfamiliar terms.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/acronyms\"\u003eSee the acronym list here\u003c/a\u003e.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Framework\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAs an ISSO, your daily tasks support CMS in applying the NIST Cybersecurity Framework (CSF), guidance created by the National Institute of Standards and Technology to help organizations effectively manage cybersecurity risk. (Executive Order 13800, \u003ca href=\"https://www.federalregister.gov/documents/2017/05/16/2017-10004/strengthening-the-cybersecurity-of-federal-networks-and-critical-infrastructure\"\u003eStrengthening the Cybersecurity of Federal Networks and Critical Infrastructure\u003c/a\u003e, made the Framework mandatory for U.S. federal government agencies.)\u003c/p\u003e\u003cp\u003eWe have created the \u003cstrong\u003eISSO Framework\u003c/strong\u003e to show how ISSO responsibilities align with specific functions and categories of the NIST Cybersecurity Framework, and how the ISSO works with other people within the organization to complete tasks. You can refer to this Framework whenever you have questions about documentation or activities related to your job.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://share.cms.gov/Office/OIT/ISPG/DSPC/ISPG%20DSPC%20Documents%20%20Internal/ISSO%20Engagement%20and%20Outreach%20Initiative/ISSO%20Framework\"\u003eGo to the ISSO Framework\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity and Privacy Language for IT Procurements\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS provides templated language to use in IT procurements to ensure the security and privacy of information and information systems that CMS uses. This includes systems provided or managed by contractors or subcontractors on behalf of CMS. The ISSO may provide support to this process.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-and-privacy-requirements-it-procurements\"\u003eLearn more about Security and Privacy Language for IT Procurements\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eTarget Life Cycle (TLC)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS requires all new IT systems to follow the Target Life Cycle (TLC), a common framework for governing system development across the enterprise. The TLC accommodates various IT development methodologies while ensuring that systems meet all applicable legislative and policy requirements.\u0026nbsp;\u003c/p\u003e\u003cp\u003e(The TLC has replaced the former Expedited Life Cycle (XLC) as the official IT governance framework at CMS. If your current projects or contracts specify the use of XLC-related tools, templates, or reviews, you may continue using them.\u0026nbsp; You may also use fewer or alternative tools and templates, as long as you meet the minimum requirements outlined within the TLC.)\u003c/p\u003e\u003cp\u003eAs an ISSO, you will enter the TLC by filling out an intake form when:\u003c/p\u003e\u003cul\u003e\u003cli\u003eInitiate a new IT project\u003c/li\u003e\u003cli\u003eConduct an acquisition to support a new IT project\u003c/li\u003e\u003cli\u003eRequest new/increased funding to support an IT project\u0026nbsp;\u003c/li\u003e\u003cli\u003ePlan significant changes to an existing IT project\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAfter submitting your form, the CMS IT Governance Team will help you meet TLC requirements. You can also contact the governance team via email: \u003ca href=\"mailto:IT_Governance@cms.hhs.gov\"\u003eIT_Governance@cms.hhs.gov\u003c/a\u003e\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/TLC\"\u003eLearn more about the TLC\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://share.cms.gov/Office/OIT/CIOCorner/Lists/Intake/NewForm.aspx\"\u003eFill out an intake form\u003c/a\u003e (requires CMS login)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eResources external to CMS\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eHHS Policy for Information Security and Privacy Protection (IS2P)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe Department of Health and Human Services (HHS) is the parent organization for CMS. All of our policies and guidance are based on HHS-level documentation. The IS2P comprises HHS policies and procedures that ensure the secure collection, use, sharing, and storage of information that is both terrorism-related information and “protected information (PI)”.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWhere possible, this document identifies existing HHS policies and procedures that meet the privacy requirements. Where necessary, however, this document also creates policies specific to the activities and resources that HHS requires.\u0026nbsp; The IS2P is one of the base documents from which CMS requirements are created. You can request a copy of this policy from the CISO team: \u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003eCISO@cms.hhs.gov\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eHHS Cybersecurity Library\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSometimes CMS borrows policies and standards directly from HHS, our parent organization. You will sometimes need to access the HHS library of cybersecurity documents for your work.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://intranet.hhs.gov/security/index.html\"\u003eGo to the HHS library\u003c/a\u003e (requires login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNIST Special Publications\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eNIST Special Publications in the 800 series are of general interest to the computer security community, and these documents serve as the foundation for CMS security and privacy practices. Specifically helpful to ISSOs are the publications that contain detailed explanations of information security controls and the test cases used to assess them.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53: Recommended Security Controls for Federal Information Systems\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final\"\u003eNIST SP 800-53A: Guide for Assessing the Security Controls in Federal Information Systems\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-800-series-of-special-publications\"\u003eLearn more about NIST SP 800 series\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNIST Computer Security Resource Center\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe National Institute of Standards and Technology (NIST) publishes helpful resources on computer, cyber, and information security and privacy. Explore publications, news, programs, and events that will help you expand your cybersecurity knowledge.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/\"\u003eVisit the NIST Resource Center\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eOMB Memoranda and Circulars\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eEvery year, the Office of Management and Budget (OMB) publishes a Memo with reporting instructions and guidance for FISMA, which can be useful to people with cybersecurity responsibilities at CMS. \u003ca href=\"https://www.whitehouse.gov/omb/information-for-agencies/memoranda/\"\u003eExplore OMB memos here\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eThere are a number of OMB Circulars that provide general guidance on information security. Three of the most relevant are:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/omb/circulars_a130_a130appendix_iii\"\u003eA-130 - Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.osec.doc.gov/opog/privacy/Memorandums/OMB_Circular_A-123.pdf\"\u003eA-123 - Management's Responsibility for Internal Control\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/omb/circulars_a127/\"\u003eA-127 - Financial Management Systems\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eOMB A-130 applies to all IT systems while A-123 and A-127 apply primarily to financial systems. ISSOs should be aware of these foundation documents and have a general understanding of their content. \u003ca href=\"https://www.whitehouse.gov/omb/information-for-agencies/circulars/\"\u003eExplore all OMB Circulars here\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho to contact\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWhen you have a question or challenge, we are here to help! Here are key points of contact for situations you may face as an ISSO.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity or privacy incident\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eReport known or suspected security or privacy incidents involving CMS data to the CMS IT Service Desk by calling 410-786-2580 or 1-800-562-1963 or via e-mail to \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity or privacy questions\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eDo you have a question or concern related to CMS information security or privacy, and need a place to start? Send an email to the CISO Team at \u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003eCISO@cms.hhs.gov\u003c/a\u003e regarding information security, or an email to \u003ca href=\"mailto:Privacy@cms.hhs.gov\"\u003eprivacy@cms.hhs.gov\u003c/a\u003e for questions regarding information privacy.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eISSO questions\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eIf you have questions about the ISSO role or other activities such as the ISSO Forum —or if you just want to hear from an ISSO — send an email to \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eOversight and guidance\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Cyber Risk Advisor (CRA) and Privacy Advisor are your ISPG support representatives. They help improve accountability and risk management by providing hands-on oversight to system cybersecurity and privacy risk.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eISSO community\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCMS Cybersecurity Community Forum (C3F)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis monthly meeting is held for the benefit of the CMS security community, covering timely and relevant topics from ISPG speakers. It’s open to all CMS and contractor security professionals. Meeting details (location, time, video conferencing link) will be in the email invitation, which is sent monthly to everyone at CMS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://confluenceent.cms.gov/pages/viewpage.action?spaceKey=IIP\u0026amp;title=CMS+ISSO+Forum\"\u003eSee past Forum videos and materials\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Journal\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eRead the ISSO Journal to stay updated on cybersecurity trends, learn about current events, and hear from other ISSOs. The Journal is distributed widely among CMS staff, and all cybersecurity professionals – both CMS and contractor staff – are invited to contribute! Contact us by email (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e) if you would like to write a post.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://confluenceent.cms.gov/pages/viewpage.action?spaceKey=IIP\u0026amp;title=CMS+ISSO+Journal\"\u003eRead the ISSO Journal\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Mentorship Program\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe mentorship program allows experienced ISSOs to support those who are newer to the role. For mentors, this is an opportunity to build leadership skills and strengthen the future of cybersecurity at CMS. For mentees, this allows you to build your knowledge faster and get hands-on support. The structure of the program is flexible — both ISSOs will decide what cadence and duration for meetings works for them.\u0026nbsp;\u003c/p\u003e\u003cp\u003eA mentorship usually lasts 6 months to a year. Your supervisor will need to approve your participation in the program.\u0026nbsp; Note that although the program is generally used by newer ISSOs, it is also available for existing ISSOs who want additional bootstrap help – for example, if they are dealing with an issue or project that is new to them. Mentorship is for these ISSOs, too!\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/isso-mentorship-program\"\u003eLearn about the ISSO Mentorship Program\u003c/a\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eTraining\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePeople come to the ISSO role from many backgrounds, with differing experiences, so each may start at a different place. Broadly, ISSOs need to have both general cybersecurity knowledge and specific knowledge of how things operate at CMS. For new ISSOs, see the “Getting Started” section of this Handbook for tips on beginning your training journey.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNICE code for ISSOs\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere is a Federal initiative to help train cybersecurity professionals. The \u003ca href=\"https://www.nist.gov/itl/applied-cybersecurity/nice\"\u003eNational Initiative for Cybersecurity Education\u003c/a\u003e (NICE) seeks to link appropriate training to cybersecurity roles by associating NICE “codes” with training opportunities. \u003cstrong\u003eAs an ISSO, your NICE code is OV‐MGT‐001\u003c/strong\u003e. Knowing this will help you find appropriate training for particular tasks or knowledge areas.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTraining sources\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere are many external sources – such as professional associations and training organizations – that can help you expand your cybersecurity knowledge and skills, but you can also get excellent free training that is provided by CMS and HHS. They are offered via the following platforms:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"http://www.cms.gov/cbt\"\u003eCMS Computer Based Training\u003c/a\u003e (CBT) - Free online training courses provided by CMS\u003c/li\u003e\u003cli\u003eCMS Cybersecurity Training Catalog - List of current training offerings and events (such as webinars) from CMS\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://confluenceent.cms.gov/display/IIP/ISSO+Training\"\u003eISSO Training Page\u003c/a\u003e - Collection of training resources in the ISPG Confluence environment that helps you navigate the training options available to you\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://ams.hhs.gov/amsLogin/SimpleLogin.jsp\"\u003eHHS Learning Management System\u003c/a\u003e\u0026nbsp; (LMS) - Free courses for federal employees (not contractors) provided through HHS to advance your core cybersecurity knowledge or prepare you for certifications\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://fedvte.usalearning.gov/\"\u003eFederal Virtual Training Environment\u003c/a\u003e (FedVTE) - Another source of free training courses available to federal employees and contractors (similar to the LMS above).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eTo help ISSOs focus on the most relevant training, below is a list of Basic, Intermediate, and Advanced courses that will help you grow in the specific skills needed for your role.\u003c/p\u003e\u003ch4\u003eBasic ISSO training\u003c/h4\u003e\u003cp\u003eThe courses recommended below provide both an introduction to cybersecurity in general and guidance on how these concepts are implemented at CMS. The courses listed in bold are the most important. You should consider some or all of the rest of the courses as your time permits. If possible, try to complete the bolded courses within your first two months as an ISSO. There is no cost to take these courses. Note: HHS LMS is only available to federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eISSO Fundamentals\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWorking With CFACTS\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eClassroom / Remote\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eAll About the CMS Acceptable Risk Safeguards (ARS 5.1)\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePrivacy and Awareness Training\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eExecutive’s Guide to Security: Protecting Your Information\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Awareness: Getting Started with Security Foundations, Information Security Fundamentals, and Key Security Terms\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompliance Expert: IT Security - Phishing, Safeguarding Mobile Devices, and Privacy \u0026amp; Information Security (The Basics)\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity 101: Auditing \u0026amp; Incident Response and Session \u0026amp; Risk Management\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003eIntermediate ISSO training\u003c/h4\u003e\u003cp\u003eThe courses recommended below will build on your initial knowledge. As before, you should start with the courses listed in bold, or on topics that have immediate importance to you. There is no cost to take these courses. Note: HHS LMS is only available for federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eNavigating New Cybersecurity and Privacy Policies and Procedures\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eHow Hackers Hack and How to Protect Yourself\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eIncident Response at CMS\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCMS Privacy Incident Response: Quick Guide for Business Owners\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Race\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eFundamentals of Cyber Risk Management\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFoundations of Incident Management\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompliance Expert: IT Security - Phishing\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Audits\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eImplementation of Security Controls\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003eAdvanced ISSO training\u003c/h4\u003e\u003cp\u003eThe advanced courses recommended below will help you gain a deeper understanding of the cybersecurity issues that you have been working with. They may also be appropriate to take earlier if you entered the ISSO role with a good basic understanding of both CMS operations and cybersecurity in general. There is no cost to take these courses.\u0026nbsp; Note: HHS LMS is only available for federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eEmerging Cyber Security Threats\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecuring Infrastructure Devices\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecuring the Network Perimeter\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Computing Fundamentals: Cloud Security\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Architecture\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Security\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Platforms\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCloud Security Fundamentals\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA A+: Security Fundamentals\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eEncryption and Malware\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA Server+: Network Security Protocols\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA Cloud+\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e"])</script><script>self.__next_f.push([1,"2c9:T12321,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis handbook gives practical guidance to Information System Security Officers (ISSO)s at CMS when performing their necessary tasks.\u0026nbsp; It helps new ISSOs get started and explains the responsibilities, resources, and organizational relationships needed for an ISSO to be successful.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis guide is for CMS (Federal) ISSOs, Contractor ISSOs, and contract security support individuals.\u0026nbsp; Business Owners and their staff may also find parts of this handbook useful, particularly when appointing new ISSOs or gaining a better understanding of ISSO tasks.\u003c/p\u003e\u003cp\u003eThe ISSO role is critical to the safe and authorized use of sensitive information in support of CMS’ commitment to improving healthcare for millions of Americans. As an ISSO,\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat do ISSOs do?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eEvery CMS system must formally designate an ISSO who serves as the primary point of contact responsible for the system’s security and privacy.\u0026nbsp;\u003c/p\u003e\u003cp\u003eISSOs at CMS are responsible for overseeing the security and privacy posture of the system(s) entrusted to their care, coordinating all information system risk management and information privacy activities, and acting as the Business Owner’s “go-to person” for security questions and needs. Together, the ISSOs make up a supportive community working to ensure the success of the cybersecurity program at CMS.\u003c/p\u003e\u003cp\u003eFor more details, see the section on role and responsibilities.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho do ISSOs work with?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO is part of the\u003cstrong\u003e portfolio team\u003c/strong\u003e – the group of people who work together to make sure that any given CMS information system complies with federal security requirements and is managed in a way that protects the personal and health information of those who depend on CMS for benefits. The portfolio team has the following roles:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eProgram Executive, Information System Owner (ISO), Business Owner (BO), and Information System Security Officer (ISSO)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThese people work together to take full responsibility for implementing the required security and privacy controls and managing the cybersecurity and privacy risk posture for each system. All of these roles must be an agency official (federal government employee) except the ISSO, which may be a federal employee or a contractor.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCyber Risk Advisor (CRA)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eCRAs are the “go-to” experts in all areas of risk management, and as such they evaluate and communicate the risk posture of each FISMA system to executive leadership and make risk-based recommendations to the Authorizing Official. CRAs also help to identify the types of information processed by a system, assign the appropriate security categorizations, determine the privacy impacts, and manage information security and privacy risk. They facilitate the completion of all federal cybersecurity and privacy requirements – and this means that CRAs and ISSOs often work closely together.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eData Guardian\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Data Guardian coordinates CMS Program activities involving beneficiary and other types of consumer information that require privacy protections.\u0026nbsp; The Data Guardian must be an agency official (federal government employee) and must fulfill shared responsibilities with the CMS Business Owner.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePrivacy Advisor\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Privacy Advisor is a member of ISPG who provides privacy-related expertise to help the team identify and manage privacy risk.\u0026nbsp; The Privacy Advisor is an agency official (federal government employee) and serves as a point of contact for issues related to the Privacy Act. They also support the completion of privacy-related artifacts such as Systems of Records Notice (SORN), Privacy Act reviews, and FISMA and Privacy Management Report.\u003c/p\u003e\u003cp\u003eDetailed information about all of these roles can be found in the CMS Information Security and Privacy Policy (IS2P2) and the HHS Policy for Information Security and Privacy Protection (IS2P).\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWhat should an ISSO know?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe goal of every ISSO should be to support the BO to securely provide the service intended by the system. To help accomplish this goal, an ISSO should ideally know and understand their component’s business processes and how the system supports that business. This knowledge is critically applied during the construction of the System Security and Privacy Plan (SSPP).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eInformation security is a means to an end and not the end in itself\u003c/strong\u003e. In the public sector, information security is secondary to the agency's services provided to its constituency. We, as security professionals, must not lose sight of these goals and objectives.\u003c/p\u003e\u003cp\u003eIn order to help the BO provide a CMS service in a manner that is demonstrably secure and safeguards any sensitive beneficiary information, the ISSO must know (at a minimum):\u003c/p\u003e\u003cul\u003e\u003cli\u003eMission and business functions of their component\u003c/li\u003e\u003cli\u003eHow the system supports the component’s mission\u003c/li\u003e\u003cli\u003eSystem details, including:\u003cul\u003e\u003cli\u003eArchitecture\u003c/li\u003e\u003cli\u003eSystem components (hardware, software, peripherals, etc.)\u003c/li\u003e\u003cli\u003eLocation of each system component\u003c/li\u003e\u003cli\u003eData flow\u003c/li\u003e\u003cli\u003eInterconnections (internal and external)\u003c/li\u003e\u003cli\u003eSecurity categorization\u0026nbsp;\u003c/li\u003e\u003cli\u003eSecurity requirements\u003c/li\u003e\u003cli\u003eConfiguration management processes and procedures\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eUsers (how many, location, role, etc.)\u003c/li\u003e\u003cli\u003eKey personnel by name\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eHow are ISSOs appointed?\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe CMS Program Executive in coordination with the Data Guardian, ISO, and Business Owner, is responsible for nominating appropriately qualified ISSO appointees, as defined under FISMA, to the CISO for approval.\u003c/p\u003e\u003cp\u003eThe nominated ISSO, by signing the appointment letter, agrees to maintain the appropriate operational security posture of the information system by fulfilling all of the responsibilities identified in the \u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eCMS Information Security and Privacy Policy (IS2P2)\u003c/a\u003e and the HHS Policy for Information Security and Privacy Protection (IS2P).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eA subset of the ISSO’s duties and responsibilities is contained in the \u003ca href=\"/learn/isso-appointment-letter\"\u003eappointment letter\u003c/a\u003e. ISSO letters must be updated whenever a change occurs. The designated ISSO should be consistently identified in three sources: the ISSO letter, the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e, and in \u003ca href=\"/learn/cms-fisma-continuous-tracking-system-cfacts\"\u003eCFACTS\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe signed appointment letter should be given to the appropriate CRA for further action.\u0026nbsp;\u003cstrong\u003e It is the responsibility of the CRA to upload the letter to CFACTS\u003c/strong\u003e.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eGetting started (for new ISSOs)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eCongratulations on your new assignment as an Information System Security Officer (ISSO) at CMS! Because you are charged with protecting the sensitive information contained in systems that support healthcare delivery for millions of people, your role is vital to the success of CMS’ mission. You will learn how to identify and protect information that includes:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePersonally Identifiable Information (PII)\u003c/li\u003e\u003cli\u003eIndividually Identifiable Information (IIF)\u003c/li\u003e\u003cli\u003eProtected Health Information (PHI)\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis means that security must become a vital part of your daily routine and always top-of-mind. Your training as an ISSO will ensure that you know and understand the requirements for protecting government assets like classified information, property, and personnel.\u003c/p\u003e\u003cp\u003eMost importantly, you will learn to work as part of a team that is dedicated to making sure CMS information systems can operate securely. While CMS has established a security program to protect assets and keep sensitive information safe, the key ingredient is always \u003cstrong\u003epeople\u003c/strong\u003e. No matter how comprehensive a program may be, you and your coworkers will ultimately determine the success of our established procedures.\u0026nbsp;\u003c/p\u003e\u003cp\u003eAnd we are here to help you along the way! This Handbook is your primary resource for initial information about your role, and will direct you to other sources of help and support.\u003c/p\u003e\u003cp\u003eHere are the steps you should take to get started:\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eComplete the paperwork\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIf you have not already, make sure that your \u003ca href=\"/learn/isso-appointment-letter\"\u003e\u003cstrong\u003eISSO Appointment Letter\u003c/strong\u003e\u003c/a\u003e is completed and submitted to your Cyber Risk Advisor (CRA) by your Business Owner (BO). The Appointment Letter is intended to formally nominate you as an ISSO. It also gives you a wealth of information about your duties and responsibilities. It also contains the qualifications and training to which you should aspire. This document may be your first communication with your CRA — the first of many conversations.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf you need a copy of the ISSO Appointment Letter template, contact the ISSO Support Team: \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eComplete ISSO onboarding\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe ISSO Support team in ISPG can help get you started. You should ask for an initial meeting with the team to orient you to your new role and next steps. \u0026nbsp; You should also reach out to your CRA, who may wish to meet on a regular basis initially, especially if your system has an important near-term milestone. If your BO did not set this up for you, you can do it yourself by sending a note to \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e. It is helpful to put the word “Onboarding” in the subject line.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eKnow your systems\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eMake sure that in your conversation with your Business Owner, you understand whether you are going to be the primary ISSO (or the only ISSO), or if you are going to be an assistant. Do you know where your system is located? When does the Authority to Operate (ATO) expire? Are you working on a new system? The more you know at the beginning, the easier it will be to prioritize and to work with your integrated team. If you have questions about any of this, reach out to the ISSO Support Team (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e).\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eMeet your team\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIn addition to your BO and your CRA, there are others that you should get to know. We recommend that you reach out to them. We also recommend face to face meetings, at least initially. Some others you should get to know include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eOther ISSOs in your component, if applicable\u003c/li\u003e\u003cli\u003eYour system’s Technical Lead\u003c/li\u003e\u003cli\u003eWhen appropriate, your system’s contractor security support\u003c/li\u003e\u003cli\u003eThe ISSO Support Team (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eAssess your skills with the ISSO Score Card\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eISSOs come from many backgrounds, both technical and non-technical. Even new ISSOs with a technical background may not be familiar with the “CMS way” of operating. While you will be busy with your new role, you should take some initial time to get a better awareness of your capabilities to be a CMS ISSO through some focused initial training.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWe’ve made it easy to figure out what training you should prioritize using a self-assessment tool: the \u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eISSO Score Card.\u003c/a\u003e Every ISSO is encouraged to take this assessment regularly as their knowledge expands. The ISSO Score Card is:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eConfidential\u003c/strong\u003e - only you will see the results\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eQuick\u003c/strong\u003e - only taking 10-15 minutes to complete\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eGeared to ISSO duties\u003c/strong\u003e - taken directly from CMS policies and requirements\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePersonalized\u003c/strong\u003e - you’ll get a customized report to help you make a training plan\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eEasy\u003c/strong\u003e - using a simple online web interface\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eGo to the ISSO Score Card\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eSign up for training\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAs an ISSO, it is vital that you understand security and privacy fundamentals and how they are applied at CMS. Regardless of your prior level of experience, you will need to know the CMS-specific workflows and governance. There is a wealth of training available to you, both for getting started and deepening your knowledge.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eWondering where to start\u003c/strong\u003e? Here’s a simple checklist to make sure you complete the essential training that will start you on the road to success:\u003c/p\u003e\u003cul\u003e\u003cli\u003eFigure out what you need to know (or brush up on) using the \u003ca href=\"https://cms-lms.usalearning.net/mod/quiz/view.php?id=389\"\u003eISSO Score Card\u003c/a\u003e. Use the results to sign up for training that is customized to your level.\u003c/li\u003e\u003cli\u003eLearn about 6 key job functions of ISSOs using the \u003ca href=\"https://www.cms.gov/cbt/login/default.aspx\"\u003evideo training series from CMS\u003c/a\u003e.\u003c/li\u003e\u003cli\u003eSign up for CFACTS training – it’s worth the 2-day time investment to get a solid grasp on this essential tool for the ISSO’s daily work. (This is available in the CMS Computer Based Training platform).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFinally, to build upon the checklist above, we have provided a list of Basic, Intermediate, and Advanced ISSO training courses that are free for you to take. See the Training section of this Handbook for details.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eGet a mentor\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOptionally, you can join the \u003ca href=\"/learn/isso-mentorship-program\"\u003e\u003cstrong\u003eISSO Mentorship Program\u003c/strong\u003e\u003c/a\u003e to be paired with an experienced ISSO. Once paired, you should work together to develop a cadence for meeting and knowledge sharing. This allows you to gain confidence faster and get hands-on support. Learn more about the ISSO Mentorship Program here.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eJoin the community\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe cybersecurity community at CMS is alive and growing. There are all kinds of ways that you can get involved, get an idea of what’s going on at CMS, and learn how it affects you. Attend the CMS Cybersecurity Community Forum, read the ISSO Journal, and look for ISPG-sponsored security and privacy activities.\u003c/p\u003e\u003cp\u003eFinally, if you have any questions along the way, just ask. Your job is very important to the success of CMS programs, and everyone at ISPG is here to support you!\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eGoals for your first year\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eBy the end of your first year as an ISSO, it should be your goal to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eLearn the security planning and administrative security procedures for systems that process sensitive information such as PHI, PII, FTI, and classified and national intelligence data\u003c/li\u003e\u003cli\u003eUnderstand the implementation and enforcement of CMS’ Information System Security and Privacy policies and practices\u0026nbsp;\u003c/li\u003e\u003cli\u003eKnow the concerns and requirements that determine the administration and management of physical, system, and data access controls based on the sensitivity of the data processed and the corresponding authorization requirements\u003c/li\u003e\u003cli\u003eLearn the identification, analysis, assessment and evaluation of information system threats and vulnerabilities and their impact on their component’s critical information infrastructures\u003c/li\u003e\u003cli\u003eBe able to identify management, technical, personnel, operational and physical security controls\u003c/li\u003e\u003cli\u003eUnderstand any additional critical areas of knowledge related to your system\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eRole and responsibilities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eISSOs maintain a strong security and privacy posture for their assigned system(s) in the following high-level ways:\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eServe as principal advisor\u003c/strong\u003e to the System Owner (SO), Business Owner (BO), and the Chief Information Security Officer (CISO) on all system security and privacy matters\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMaintain system authorization \u003c/strong\u003eby following the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-risk-management-framework-rmf\"\u003eNIST Risk Management Framework\u003c/a\u003e to select, implement, document, test, and maintain the security and privacy controls required to authorize and operate information systems within CMS’s risk tolerance throughout the \u003ca href=\"https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/tlc\"\u003eTarget Life Cycle\u003c/a\u003e (TLC)\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMaintain security and privacy operations\u003c/strong\u003e capabilities sufficient to identify, detect, protect, respond, and recover from security incidents (as per the \u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-cybersecurity-framework-csf\"\u003eNIST Cybersecurity Framework\u003c/a\u003e)\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eMeet federal reporting requirements\u003c/strong\u003e for information security and privacy, including documenting and mitigating weaknesses and reporting incidents and breaches\u003c/p\u003e\u003cp\u003e• \u003cstrong\u003eManage privacy requirements\u003c/strong\u003e by working collaboratively with Data Guardians and Privacy Advisors\u003c/p\u003e\u003cp\u003eThe official role and specific responsibilities for ISSOs are outlined in detail by the CMS Information Security and Privacy Policy (IS2P2), which is based upon the related policy document from HHS (IS2P). The following list is based on those policy documents and includes some key duties for ISSOs:\u003c/p\u003e\u003cul\u003e\u003cli\u003eComplete the security categorization for the FISMA system using the CFACTS tool\u003c/li\u003e\u003cli\u003eComplete and maintain the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan\u003c/a\u003e using the CFACTS tool\u003c/li\u003e\u003cli\u003eEnsure \u003ca href=\"https://security.cms.gov/learn/cybersecurity-risk-assessment-program-csrap\"\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/a\u003e – and \u003ca href=\"/learn/penetration-testing\"\u003ePenetration Tests\u003c/a\u003e have been scheduled and completed in a timely manner\u003c/li\u003e\u003cli\u003eDevelop, document and maintain an inventory of hardware and software components within the FISMA system’s authorization boundary\u003c/li\u003e\u003cli\u003eCoordinate the development of a \u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan\u003c/a\u003e and ensure the plan is tested and maintained accordingly\u003c/li\u003e\u003cli\u003eMaintain primary responsibility for the actions and activities associated with the FISMA system receiving and maintaining an \u003ca href=\"/learn/authorization-operate-ato\"\u003eAuthority to Operate (ATO)\u003c/a\u003e\u003c/li\u003e\u003cli\u003eCoordinate with the ISO, BO, and CRA to manage information security and privacy risk\u003c/li\u003e\u003cli\u003eMonitor and update all POA\u0026amp;Ms in accordance with current requirements and instruction\u003c/li\u003e\u003cli\u003eSubmit recommendations to the CRA for system configuration deviations from the required baseline\u003c/li\u003e\u003cli\u003eIdentify the information security and privacy controls provided by the applicable infrastructure that are common controls for information systems;\u003c/li\u003e\u003cli\u003eCoordinate with the ISO, BO, and CRA to meet all collection, creation, use, dissemination, retention, and maintenance requirements for sensitive information in accordance with the Privacy Act, E-Government Act, and all other applicable guidance\u003c/li\u003e\u003cli\u003eCoordinate with the BO, Contracting Officer, ISO, and CISO to ensure that all requirements specified by the \u003ca href=\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eARS 5.1\u003c/a\u003e and the \u003ca href=\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\"\u003eRMH\u003c/a\u003e are implemented and enforced for applicable information and information systems\u003c/li\u003e\u003cli\u003eReport and manage IT Security and Privacy Incidents in accordance to the RMH and other applicable federal guidance\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eTypes of ISSO roles\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe specific type of ISSO role assigned to a system will depend on the needs of the system and the available personnel. The descriptions below are taken from the CMS Information Security and Privacy Policy (IS2P2).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrimary Information System Security Officer (P-ISSO)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS P-ISSO may be either a federal government employee or a contractor and must fulfill all of the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.24, System Security and System Privacy Officers. ISSO must ensure the duties of the Security Control Assessor and Contingency Planning Coordinator are completed as described in the IS2P Sections 7.26 and 7.30.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecondary Information System Security Officer (S-ISSO)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS S-ISSO may be either a federal government employee or a contractor identified in the IS2P Section 7.25, ISSO Designated Representative / Security Steward and must assist the P-ISSO.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInformation System Security Officer Contractor Support (ISSOCS)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe ISSOCS is a contractor-only role that assists and supports the P-ISSO and S-ISSO roles in fulfillment of their CMS cybersecurity duties.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity or Privacy Control Assessor\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Security or Privacy Control Assessor role may be performed by an ISSO. The CMS Security or Privacy Control Assessor must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.23.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eContingency Planning Coordinator\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Contingency Planning Coordinator may either be a federal government employee or a contractor. The role may also be performed by an ISSO. The CMS Contingency Planning Coordinator must fulfill all the responsibilities identified in the HHS Policy for Information Systems Security and Privacy Protection (IS2P) Section 7.30.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eISSO checklist\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThis section provides a list of specific tasks an ISSO should perform periodically. The timelines listed for each task are general guidelines, which may vary depending on the Component guidance or system circumstances. This list isn’t comprehensive, but serves as a quick reference to help you plan your work. You may choose to make a spreadsheet for yourself to keep track of recurring tasks and due dates.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eWeekly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview audit logs\u003c/li\u003e\u003cli\u003eRoutinely evaluate risk posture based upon change requests\u003c/li\u003e\u003cli\u003eEnsure data is backed up\u003c/li\u003e\u003cli\u003eCheck status of any \u003ca href=\"/learn/plan-action-and-milestones-poam\"\u003ePlan of Action and Milestones (POA\u0026amp;M)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eMonthly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview / deactivate unused accounts\u003c/li\u003e\u003cli\u003eEnsure all POA\u0026amp;Ms with Open or Delay status are annotated with current status\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eQuarterly\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eEnsure that all data in CFACTS is current and accurate one week before the end of the quarter (CMS submits a quarterly FISMA report to OMB based on this data)\u003c/li\u003e\u003cli\u003eEnsure the completion of internal vulnerability scans\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eAnnually\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eReview and update all \u003cstrong\u003eSecurity Authorization Process documentation\u003c/strong\u003e, such as those listed below. Remember that most of these require months of effort to complete, so you must be working on them well in advance.\u003cul\u003e\u003cli\u003e\u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eInformation System Risk Assessment (ISRA)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan (CP)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePrivacy Impact Assessment (PIA)\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and Privacy Plan (SSPP)\u003c/a\u003e Note: Updating security control implementation is a necessary first step to updating the SSPP. When updating any documents, ensure the old copy is retained.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eEnsure that all system users and people with significant security responsibilities (e.g., ISSOs) receive their required annual awareness training\u003c/li\u003e\u003cli\u003eConduct a Contingency Plan Test with associated training, after-action, and updated POA\u0026amp;Ms as necessary. Ensure that the Business Owner certifies (signs) any updated CP document.\u003c/li\u003e\u003cli\u003eReview the Privacy Impact Assessment (PIA) for your system(s) and update as appropriate\u003c/li\u003e\u003cli\u003eEnsure vulnerability assessments are completed at least annually, or when significant changes are made to the system\u003c/li\u003e\u003cli\u003eReview and validate user access rights\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eOngoing\u003c/strong\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eContinual security control assessment to ensure no risks are present\u003c/li\u003e\u003cli\u003eContinual work on tests and assessments (as needed) such as:\u003cul\u003e\u003cli\u003eCybersecurity and Risk Assessment Program (CSRAP)\u003c/li\u003e\u003cli\u003ePenetration Testing\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003eContinual updating of the \u003cstrong\u003eSecurity Authorization Process documentation\u003c/strong\u003e (see list in the section above). All of these should be updated as changes occur, and all require an annual review and update.\u003c/li\u003e\u003cli\u003eComplete incident response reports (as required)\u003c/li\u003e\u003cli\u003eATO updates (as required)\u003c/li\u003e\u003cli\u003eRespond to any CCIC monitoring alerts (as required)\u003c/li\u003e\u003c/ul\u003e\u003ch2\u003e\u003cstrong\u003eISSO activities\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eUse this section to learn in-depth about the activities you must understand and perform as an ISSO – from the very beginning of your system’s development. These activities support the CMS \u003ca href=\"https://www.cms.gov/research-statistics-data-and-systems/cms-information-technology/tlc\"\u003eTarget Life Cycle\u003c/a\u003e (TLC), which is the framework that standardizes how IT systems are built, maintained, and retired at CMS. The ISSO activities also support the Risk Management Framework (RMF) from NIST, which helps organizations integrate security considerations into their software development processes.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eConduct a Security Impact Analysis (SIA)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe \u003ca href=\"/learn/security-impact-analysis-sia\"\u003eSecurity Impact Analysis\u003c/a\u003e\u0026nbsp;is the process that you will use initially for your new system and \u003cstrong\u003eevery time\u003c/strong\u003e a new change to the system is proposed. When you have completed this process, you will be able to provide substantive recommendations to your Business Owner on the impact of any proposed change(s). The impact may be small, or it may rise to the level of a new ATO process.\u003c/p\u003e\u003cp\u003eNote:\u0026nbsp; SIAs are frequently thought of as documents.\u0026nbsp; Remember that \u003cstrong\u003eSIA is a process\u003c/strong\u003e.\u0026nbsp; Based on the complexity and extent of the process, a completed form may help better describe the security impact, as well as necessary actions to take.\u0026nbsp; The actual CMS/FISMA requirement noted in ARS 5.1 Control CM-4 requires “Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) to conduct security impact analyses.”\u0026nbsp; It is up to you and your Business Owner/organization to determine the level to which you document your analysis.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-impact-analysis-sia\"\u003eLearn about Security Impact Assessment (SIA)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eCategorize your FISMA system\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eYour FISMA system has different security controls based on the sensitivity of the information contained in or processed by your system. Categorization takes place within CFACTS.\u0026nbsp; You enter the appropriate area and select the type of information that will be processed.\u0026nbsp; The system categorization will be suggested automatically and noted as “Low”, “Moderate”, or “High”.\u0026nbsp; If necessary, the categorization may be manually overridden; your CRA will have to help with this.\u0026nbsp; In practice this seldom happens.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThis system categorization will have a variety of uses.\u0026nbsp; Most importantly, you will need to have this information to determine which controls to allocate for your system.\u003c/p\u003e\u003cp\u003eNote: Although this process sounds like it will only be done once for your FISMA system, \u003cstrong\u003eyou may have to repeat it\u003c/strong\u003e if a proposed change includes access or storage of different types of data. \u0026nbsp; Your completed SIA will guide your actions.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/learn/federal-information-security-modernization-act-fisma#perform-system-risk-categorization\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eLearn more about system categorization here\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://security.cms.gov/posts/watch-and-learn-system-categorization-cfacts\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eSee how to categorize your system in CFACTS\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eDetermine the Authorization Boundary\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAnother major initial task is to determine the system’s \u003cstrong\u003eAuthorization Boundary\u003c/strong\u003e. The NIST definition of authorization boundary is: “All components of an information system to be authorized for operation by an authorizing official and excludes separately authorized systems, to which the information system is connected”.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eOne practical way of determining the system’s authorization boundary is to ask whether a particular component can be changed by one’s system team, or if another team has to make updates or changes.\u0026nbsp; If your team can make the change or configuration, chances are that the component falls within your authorization boundary. As with system categorization, the authorization boundary is usually determined at the outset of system development. It may expand or contract based on changes to the system over its lifecycle.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eBe aware of High Value Assets (HVAs)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe HHS HVA Program Policy defines HVAs as: “Assets, federal information systems, information, and data for which an unauthorized access, use, disclosure, disruption, modification, or destruction could cause a significant impact to the United States’ national security interests, foreign relations, economy, or to the public confidence, civil liberties, or public health and safety of the American people.”\u003c/p\u003e\u003cp\u003eThe practical impact of this program is that, if your FISMA system is defined as an HVA, it will face additional security requirements from DHS and HHS, which may impact the continuity operations and assessments of the system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAllocate controls\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eOnce a system has been categorized, the ISSO has the information necessary to select controls, or allocate them.\u0026nbsp; The process is largely automatic, and is well-described in the CMS Risk Management Handbook (RMH) Chapter 12: Security and Privacy Planning. Selected controls are allocated for Low, Moderate, or High systems based on system categorization. The mechanics are described very well in the CFACTS User Manual, so that should be your primary reference point on allocating controls. Some general control types include:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSystem-specific controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThese are controls that your system “owns”.\u0026nbsp; If you are running on hardware that you are responsible for, there are system-specific controls for it.\u0026nbsp; If your system is an application, or Major Application, the system-specific controls are those controls that your developers and administrators configure and maintain.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInherited controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIn many cases your system uses components provided by other FISMA systems. In the above example about hardware, what if your system is housed on hardware administered by others? This is not just a possibility – in most cases major applications run within a separate data center. Certainly this is the case for systems housed in the AWS Cloud. In these instances, the data center (or other entity) that houses your system will most likely take care of some of the controls for your system – in which case your system will be able to “inherit” controls.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf the providing system completely takes care of a control, it is called a \u003cstrong\u003ecommon, or fully inherited\u003c/strong\u003e control. If the providing system takes care of part of a control, and relies on your system to take care of the rest of the control, it is called a \u003cstrong\u003ehybrid\u003c/strong\u003e control. (The CFACTS User Manual has additional information on how to inherit a control.)\u003c/p\u003e\u003cp\u003eUnderstanding which controls your team must address and which controls are available through full or partial inheritance will help you understand how to document your security control compliance (which is the next step in the cycle).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSupplemental controls\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSupplemental controls (previously referred to as non-mandatory controls in ARS 3.1) can be added to a system as necessary, and are not included in baseline control allocation. They should be reviewed and added as appropriate for your system.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eImplement security controls\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eIt is your responsibility as your system’s security and privacy Subject Matter Expert to make sure that your Business Owner, system developers, and system administrators understand the controls that must be in place for your system to be “secure” to CMS standards.\u0026nbsp; Once these controls have been implemented, \u003cstrong\u003ethey need to be documented within CFACTS\u003c/strong\u003e.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote:\u0026nbsp; All security controls that have been allocated for your system \u003cstrong\u003emust have some comment\u003c/strong\u003e. \u0026nbsp; Even fully inherited controls should have a notation that the control is fully inherited.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDevelop system documentation\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eProminent documents are important to understanding the security posture of your FISMA system.\u0026nbsp; CFACTS can help with this process by automatically generating some of the documents, such as the System Security Plan. Other documents are found within CFACTS, such as System Categorization. Others, such as the Information System Risk Assessment (ISRA) must be completed using CMS-approved templates. Finally, others may either use a CMS template or a locally generated document such as the Security Impact Assessment (SIA).\u003c/p\u003e\u003cp\u003eNote:\u003cstrong\u003e Make sure that all CFACTS entries, including all security controls, are accurate and complete at all times.\u0026nbsp;\u003c/strong\u003e This will ensure that CFACTS-generated documents are accurate.\u003c/p\u003e\u003cp\u003eItems for the system documentation include:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSystem Security and Privacy Plan (SSPP)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSSPP\u003c/a\u003e is the key document associated with the FISMA system security. It should provide an accurate, detailed description of the FISMA system itself, security requirements, and those controls that are actually in place to protect the system. This document is generated by CFACTS.\u003c/p\u003e\u003cp\u003eTip: It is a best practice to maintain older copies of SSPPs as new versions are generated. Do not overwrite old SSPPs; you never can tell when you might need to refer to an older version.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eLearn more about System Security and Privacy Plan (SSPP)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eInformation System Risk Assessment (ISRA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eISRA\u003c/a\u003e details the business and technical risks associated with a FISMA system.\u0026nbsp; It shares high-level information from CFACTS, as well as specific risks noted and how critical they are.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eLearn more about Information System Risk Assessment (ISRA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrivacy Impact Assessment (PIA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePIA\u003c/a\u003e is not simply a compliance step – it guides the full analysis of a system for privacy risks and controls. A PIA is a process for assessing whether appropriate privacy policies, procedures, business practices, and security controls are implemented to ensure compliance with federal privacy regulations. PIAs are published on HHS.gov and go through a three-year review process.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003eLearn more about Privacy Impact Assessment (PIA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eThird-Party Websites and Applications\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe \u003ca href=\"https://www.osec.doc.gov/opog/privacy/Memorandums/OMB_M-10-23.pdf\"\u003eOffice of Management and Budget Memorandum 10-23\u003c/a\u003e, Guidance for Agency Use of Third-Party Websites and Applications, requires that agencies assess their uses of third-party websites and applications to ensure that the use protects privacy. The mechanism by which agencies perform this assessment is a privacy impact assessment (PIA).\u0026nbsp;\u003c/p\u003e\u003cp\u003eIn accordance with HHS policy, operating divisions (OPDIVs) are responsible for completing and maintaining PIAs for all third-party websites and applications in use. Upon completion of each assessment, agencies are required to make the PIAs publicly available. The CMS Third-Party Websites and Applications (TPWA) Privacy Impact Assessments for each individual OPDIV system can be \u003ca href=\"https://www.hhs.gov/pia/index.html#Third-Party\"\u003eaccessed here on the HHS website\u003c/a\u003e. CMS implementation specifications are included in the CMS Acceptable Risk Safeguards (ARS 5.1).\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePrivacy Threshold Analysis\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eA Privacy Threshold Analysis (PTA) is a PIA for a system that does not contain PII or only contains HHS employee information. PTAs remain internal to HHS and do not have to go through the three-year review process. A PTA may be updated based on a major change to the system. It is also possible that change to a system could result in a PTA then meeting the threshold to be a PIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eConduct Contingency Planning (CP)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://dkanreserve.prod.acquia-sites.com/policy-guidance/risk-management-handbook-chapter-6-contingency-planning-cp\"\u003eContingency Planning\u003c/a\u003e\u0026nbsp;provides instructions, disaster declaration criteria, and procedures to recover information systems and associated services after a disruption. It involves cooperation with your Business Owner, your data center or hosting facility, and senior CMS leadership. (See CMS Risk Management Handbook Chapter 6: Contingency Planning).\u003c/p\u003e\u003cp\u003eAs the ISSO, you will coordinate efforts with your Business Owner to determine the business criticality of key processes. This effort will result in a Business Impact Analysis (BIA) which, in turn, serves as the primary requirement document for determining key recovery metrics including the Recovery Point Objective (RPO), Recovery Time Objective (RTO), Maximum Tolerable Downtime (MTD), and Work Recovery Time (WRT).\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe goal is to ensure that there are plans in place to restore business functionality within the Maximum Tolerable Downtime.\u0026nbsp; Note that this may involve restoring the system as originally constructed, moving to alternate processing facilities, or even moving to alternate processing methods.\u0026nbsp;\u003c/p\u003e\u003cp\u003eHere are the key steps and documents involved in Contingency Planning:\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCreate Contingency Plan (CP) document\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CP Plan is a single document that contains:\u003c/p\u003e\u003cul\u003e\u003cli\u003eKey recovery metrics for your FISMA system\u003c/li\u003e\u003cli\u003ePre-defined descriptions of conditions that constitute a need for action\u003c/li\u003e\u003cli\u003ePre-defined actions based on the severity of an identified incident\u003c/li\u003e\u003cli\u003eKey staff, contact information, and specific duties for each person\u003c/li\u003e\u003cli\u003eItem-level understanding of all of the hardware and software components of the FISMA system.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIt’s important to keep in mind:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe CP must be attested to (signed) by the FISMA System Owner annually.\u003c/li\u003e\u003cli\u003eAll of the information necessary for the conducting of a contingency plan must be in the CP.\u0026nbsp; There should be no references to offline personnel lists, contact information, system information, etc.\u0026nbsp;\u003c/li\u003e\u003cli\u003eAll identified Key Personnel must have access to their own copy of the CP in a secure location that is accessible in the event that the FISMA system is unavailable.\u003c/li\u003e\u003cli\u003eThe Contingency Plan, above all FISMA system documentation, must remain current.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003eConduct Contingency Plan (CP) Exercise\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CP must be exercised (tested) at least once every 365 days. This is commonly referred to as the “Tabletop Exercise”, but a tabletop exercise is only one (the easiest) way to test the CP. An exercise plan must be prepared and followed during the execution of the test. All staff who participate in an actual CP event must be available for the exercise.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote: \u003cstrong\u003eKey staff members must be trained annually in their contingency responsibilities.\u003c/strong\u003e It is best to perform this training immediately prior to the exercise. Training in this way refreshes individuals’ memories and ensures their availability for the test.\u003c/p\u003e\u003cp\u003e\u003cem\u003eTip: If your FISMA system is involved in an outage that causes you to exercise the CP Plan, you should consider documenting this event as an exercise of your CP Plan.\u003c/em\u003e\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/contingency-plan\"\u003eLearn more about Contingency Plan testing\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eGet after action report\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAfter the exercise is conducted, an after action report must be generated to describe the test and highlight specific deficiencies that must be corrected.\u0026nbsp; These deficiencies may be easily correctable, or may result in POA\u0026amp;Ms.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eAchieve Contingency Plan (CP) re-certification\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAfter any corrections have been made, the updated Contingency Plan must be re-certified by the System Owner. Make sure that all key staff members receive updated CP documents that they have access to (\u003cstrong\u003eeven away from the office or after hours\u003c/strong\u003e). Destroy (or return) older copies.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAssess security controls for your system(s)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAll CMS systems are required to undergo assessments of risk and security/privacy control compliance before they are given Authorization to Operate (ATO). The assessment and authorization process protects the security and privacy posture of CMS systems throughout the system development lifecycle.\u0026nbsp;\u003c/p\u003e\u003cp\u003eAssessments of risk and/or control compliance are conducted:\u003c/p\u003e\u003cul\u003e\u003cli\u003eWhen a new system is ready to be placed into an operational state\u003c/li\u003e\u003cli\u003eWhen a significant change has been made to an existing system\u003c/li\u003e\u003cli\u003eAnnually, if a system follows a FISMA 1/3 assessment schedule\u003c/li\u003e\u003cli\u003eAd hoc when requested or otherwise required\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCurrently there are two main types of controls assessments – SCA and ACT.\u0026nbsp; Your component will dictate which type of assessment your system undergoes.\u0026nbsp;\u003c/p\u003e\u003cp\u003eNote: Whichever one your system uses, make sure to schedule your assessment \u003cstrong\u003eas soon as possible\u003c/strong\u003e. When the assessment is complete, make sure all documentation is complete and housed in CFACTS appropriately.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity Controls Assessment (SCA)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis is a detailed evaluation of the controls protecting an information system.\u0026nbsp; The security controls assessment determines the extent to which controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-controls-assessment-sca\"\u003eLearn more about Security Controls Assessment (SCA)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCybersecurity and Risk Assessment Program (CSRAP) (Formally Adaptive Capabilities Testing (ACT))\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCSRAP is a security and risk assessment for FISMA systems at CMS. CSRAP assesses a system's security capabilities to ensure that it operates as intended and meets the security requirements for the information system. CSRAP is a critical component of the \u003ca href=\"https://cybergeek.cms.gov/learn/authorization-operate-ato\"\u003eAuthorization to Operate (ATO)\u003c/a\u003e process and is used to determine the overall system security and privacy posture throughout the system development life cycle (SDLC). For detailed information about CSRAP, see \u003ca href=\"https://confluenceent.cms.gov/download/attachments/214794255/CSRAP%20Assessment%20Handbook%20v3.1.pdf?version=1\u0026amp;modificationDate=1711993052415\u0026amp;api=v2\"\u003eCybersecurity and Risk Assessment Program Handbook\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003ePenetration testing\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePenetration testing is performed on information systems or individual system components to identify vulnerabilities that could be exploited by bad actors. It is used to validate vulnerabilities or determine the degree of resistance that organizational information systems have to risk within a set of specified constraints (e.g., time, resources, and/or skills).\u0026nbsp;\u003c/p\u003e\u003cp\u003ePenetration testing attempts to duplicate the actions of internal and external bad actors in carrying out hostile cyber-attacks against the organization and allows a more in-depth analysis. It can be conducted on the hardware, software, or firmware components of an information system and can exercise both physical and technical security controls.\u0026nbsp;\u003c/p\u003e\u003cp\u003ePenetration testing is performed on all High Value Assets (HVA) information systems within CMS at a frequency of every 365 days or when there has been a significant change to the system.\u0026nbsp;\u003c/p\u003e\u003cp\u003eIt is considered to be part of the group of assessments required for CMS systems, and its results are recorded in CFACTS similarly to the controls assessments (SCA and/or ACT).\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/penetration-testing\"\u003eLearn more about penetration testing\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity Assessment Report (SAR) and CAAT file\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eFor all assessments, a final Security Assessment Report (SAR) chronicles the results of the assessment. The \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eRisk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization\u003c/a\u003e states:\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cem\u003eAt the completion of a security controls assessment, the independent assessor completes a CMS Assessment and Audit Tracking (CAAT) spreadsheet. The CAAT spreadsheet is utilized for all CMS audits, assessments and penetration testing vulnerabilities. The completed CAAT spreadsheet is emailed to the CMS CISO mailbox at \u003c/em\u003e\u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003e\u003cem\u003eCISO@cms.hhs.gov\u003c/em\u003e\u003c/a\u003e\u003cem\u003e for upload into the CFACTS tool. Once uploaded into CFACTS, the weaknesses are automatically generated for all items with a status of “other than satisfied”. The ISSO for the associated information system receives an automated email notification from the CFACTS tool identifying a new weakness. The ISSO has 30 days to create a POA\u0026amp;M within CFACTS.\u003c/em\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManage Plan of Action and Milestones (POA\u0026amp;M)\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe POA\u0026amp;M is a remedial action plan (the process of accepting or resolving a risk) which helps the agency to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eIdentify and assess information system security and privacy weaknesses\u003c/li\u003e\u003cli\u003eSet priorities about how to mitigate weaknesses using available resources\u003c/li\u003e\u003cli\u003eMonitor and report progress toward mitigating the weaknesses\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eYou – as the ISSO – are responsible for opening, maintaining / updating, and closing POA\u0026amp;Ms on a continual basis to ensure the maximum level of information security for system(s) entrusted to your care.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/plan-action-and-milestones-poam\"\u003eLearn more about Plan of Action \u0026amp; Milestones (POA\u0026amp;M)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eAuthorize the system\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eSystem authorization is the formal decision by senior officials to allow a CMS information system to operate. Commonly known as Authorization to Operate (ATO), this is the culmination of all the tests, assessments, remediation, documentation, and other activities that the ISSO and others on the portfolio team have done to ensure information security for the system.\u003c/p\u003e\u003cp\u003eIn formal terms, authorization is described in the CMS Risk Management Handbook Chapter 4: Security Assessment and Authorization:\u003c/p\u003e\u003cp\u003e\u003cem\u003eSecurity authorizations are official management decisions that are conveyed through authorization decision documents by senior organizational officials or executives (i.e., authorizing officials) to authorize operation of information systems to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon security controls. The CIO serves as the authorizing official for CMS. The CIO is responsible for making an overall determination of risk and authorizing CMS information systems for operation, if it is determined that the associated risks are acceptable. An ATO memo is signed by the CIO giving the System Owner/BO formal authority to operate a CMS information system.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThere are three NIST document requirements for an ATO “package” and six more that are specific to CMS.\u0026nbsp; The documents include:\u003c/p\u003e\u003cul\u003e\u003cli\u003eSystem Security and Privacy Plan (SSPP)\u003c/li\u003e\u003cli\u003eSecurity Assessment (Final) Report (SAR)\u003c/li\u003e\u003cli\u003ePlans of Action and Milestones (POA\u0026amp;M)\u003c/li\u003e\u003cli\u003eContingency Plan (CP)\u003c/li\u003e\u003cli\u003eCP Testing Plan\u003c/li\u003e\u003cli\u003eCP Test After Action Report\u003c/li\u003e\u003cli\u003eInformation System Risk Assessment (ISRA)\u003c/li\u003e\u003cli\u003ePrivacy Impact Assessment (PIA)\u003c/li\u003e\u003cli\u003eInterconnection Security Agreement (ISA) – as applicable\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eGetting these documents together and conducting all necessary steps can be a long process – so \u003cstrong\u003eyou should start working on your ATO as early as possible\u003c/strong\u003e to ensure timely completion.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/authorization-operate-ato\"\u003eLearn more about System Authorization\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eContinuous monitoring\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eContinuous monitoring is the practice of using modern tools and technology to continuously check systems for vulnerabilities and risks. Rather than thinking of getting an ATO as having “achieved” compliance, continuous monitoring allows us to observe and track evolving risks over time. Security is never “done”.\u003c/p\u003e\u003cp\u003eContinuous monitoring is a growing program at CMS. As an ISSO, you will work closely with the CMS Cybersecurity Integration Center (CCIC) to ensure that your system is appropriately monitored.\u0026nbsp; CCIC ensures oversight of information security and privacy, including Security Information Event Management, for each FISMA system operating by or on behalf of CMS.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe CCIC delivers various agency-wide security services.\u0026nbsp; These services include \u003ca href=\"/learn/continuous-diagnostics-and-mitigation-cdm\"\u003eContinuous Diagnostics and Mitigation (CDM)\u003c/a\u003e as well as security engineering, incident management, forensics and malware analysis, information sharing, cyber threat intelligence, penetration testing, and software assurance.\u003c/p\u003e\u003cp\u003eMore information about continuous monitoring can be found in the \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-4-security-assessment-authorization-ca\"\u003eCMS Risk Management Handbook (RMH) Chapter 4: Security Assessment and Authorization\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eManage security incidents\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eAlong the way, a system entrusted to your care might have a security or privacy incident or breach. Anytime there is a violation of computer security policies, acceptable use policies, or standard security practices at CMS, it is considered an\u003cstrong\u003e incident\u003c/strong\u003e. If an incident involves the loss of control or unauthorized disclosure of Personally Identifiable Information (PII), then the incident is considered a \u003cstrong\u003ebreach\u003c/strong\u003e.\u003c/p\u003e\u003cp\u003eKnown or suspected security or privacy incidents involving CMS information or information systems \u003cstrong\u003emust be reported immediately\u003c/strong\u003e to the CMS IT Service Desk:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePhone: 410-786-2580 or 1-800-562-1963\u003c/li\u003e\u003cli\u003eEmail: \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e.\u0026nbsp;\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eYou as the ISSO should be apprised of the situation as soon as possible (if you’re not the one who initially reported the incident). You will work with the Incident Management Team (IMT) and others involved with your system to manage and report the incident and mitigate any resulting harm. More details can be found in the CMS Risk Management Handbook (RMH) Chapter 8: Incident Response.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eISSO toolkit\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThis section contains links to documents you will access often in your daily activities, and resources to support your work as an ISSO. You should become familiar with the purpose and usage of each.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eDocuments\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCMS Acceptable Risk Safeguards (ARS 5.1)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe CMS Information Security Acceptable Risk Safeguards (ARS 5.1) defines information security and privacy control requirements and includes additional, detailed policy traceability statements within each control description. The ARS 5.1 provides guidance on customizing (tailoring) controls and enhancements for specific types of missions/business functions, technologies, or environments of operation. Users of the ARS 5.1 may tailor specific mandatory controls as well as most of the non-mandatory and unselected controls.\u003c/p\u003e\u003cp\u003eThe goal of the ARS 5.1 is to define a baseline of minimum information security and privacy assurance controls. The controls are based on both internal CMS governance documents and laws, regulations, and other authorities created by institutions external to CMS. Protecting and ensuring the confidentiality, integrity, and availability for all of CMS’ information and information systems is the primary purpose of the information security and privacy assurance program. The ARS 5.1 complies with the CMS IS2P2 by providing a defense-in-depth security structure along with a least-privilege, need-to-know basis for all information access.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cybergeek.cms.gov/policy-guidance/cms-acceptable-risk-safeguards-ars\"\u003eLearn more about ARS 5.1\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Information Security and Privacy Policy (IS2P2)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis policy defines the framework under which CMS protects and controls access to CMS information and information systems. It provides direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems; systems maintained on behalf of CMS; and other collections of information to assure the confidentiality, integrity, and availability of CMS information and systems.\u0026nbsp;\u0026nbsp;\u003c/p\u003e\u003cp\u003eAlong with the Acceptable Risk Safeguards (ARS 5.1), the IS2P2 stands as one of the core reference sources for cybersecurity policies and practices at CMS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/policy-guidance/cms-information-systems-security-and-privacy-policy-is2p2\"\u003eGo to the IS2P2\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Risk Management Handbooks\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis series of handbooks is designed to help ISSOs understand and address the many CMS security and privacy requirements developed to protect their system(s). The RMH chapters are generally aligned to provide specific guidance and recommendations for specific ARS 5.1 Control Families. (For example, \u003cstrong\u003eRMH Chapter 6: Contingency Planning\u003c/strong\u003e addresses the ARS 5.1 controls in the \u003cstrong\u003eCP Family\u003c/strong\u003e.) As you work through your ARS 5.1 controls, you should have the appropriate RMH handy.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\"\u003eLearn more about the CMS Risk Management Handbook (RMH)\u003c/a\u003e\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTools and resources\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCFACTS\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS FISMA Controls Tracking System (CFACTS) is the system used by CMS as a repository for managing the security and privacy requirements of its information systems. It provides a common foundation to manage policies, controls, risks, assessments, and deficiencies across the CMS enterprise. You will use it for tracking your tasks associated with system authorization, risk remediation, and more.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cfacts3.cms.cmsnet/apps/ArcherApp/Home.aspx#home\"\u003eGo to CFACTS\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003cp\u003eA user manual is produced by the team that administers CFACTS and gives a guided tour through all activities in CFACTS. Although it is not a primer in risk management, many activities and concepts can be understood implicitly through their description in the User Manual and implementation in CFACTS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://cfacts3.cms.cmsnet/apps/ArcherApp/Home.aspx\"\u003eGo to CFACTS user manual\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISPG website (CyberGeek)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe Information Security and Privacy Group (ISPG) provides the “CyberGeek” website as a one-stop shop for all security and privacy related information at CMS – including dedicated resource pages for ISSOs and other roles. This is a new site, and more information will become available as it grows.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://security.cms.gov/\"\u003eGo to ISPG website (CyberGeek)\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eCMS Slack\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSlack is an application that allows for fast and easy communication among all CMS employees and contractors. Spaces called channels allow for focused communication which will keep you organized and informed during your daily routine. Below is a list of Slack channels that will help you on your journey to becoming a fully independent ISSO:\u003c/p\u003e\u003cul\u003e\u003cli\u003e#ars-feedback\u003c/li\u003e\u003cli\u003e#cfacts_community\u003c/li\u003e\u003cli\u003e#cisab\u003c/li\u003e\u003cli\u003e#cms-isso\u003c/li\u003e\u003cli\u003e#cyber-risk-management\u003c/li\u003e\u003cli\u003e#ispg-all\u003c/li\u003e\u003cli\u003e#isso-as-a-service\u003c/li\u003e\u003cli\u003e#security_community\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAcronyms\u003c/h4\u003e\u003cp\u003eLike most other parts of government, the security and privacy world at CMS is full of acronyms. ISPG maintains a list of acronyms so you can easily look up unfamiliar terms.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/acronyms\"\u003eSee the acronym list here\u003c/a\u003e.\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Framework\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eAs an ISSO, your daily tasks support CMS in applying the NIST Cybersecurity Framework (CSF), guidance created by the National Institute of Standards and Technology to help organizations effectively manage cybersecurity risk. (Executive Order 13800, \u003ca href=\"https://www.federalregister.gov/documents/2017/05/16/2017-10004/strengthening-the-cybersecurity-of-federal-networks-and-critical-infrastructure\"\u003eStrengthening the Cybersecurity of Federal Networks and Critical Infrastructure\u003c/a\u003e, made the Framework mandatory for U.S. federal government agencies.)\u003c/p\u003e\u003cp\u003eWe have created the \u003cstrong\u003eISSO Framework\u003c/strong\u003e to show how ISSO responsibilities align with specific functions and categories of the NIST Cybersecurity Framework, and how the ISSO works with other people within the organization to complete tasks. You can refer to this Framework whenever you have questions about documentation or activities related to your job.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://share.cms.gov/Office/OIT/ISPG/DSPC/ISPG%20DSPC%20Documents%20%20Internal/ISSO%20Engagement%20and%20Outreach%20Initiative/ISSO%20Framework\"\u003eGo to the ISSO Framework\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSecurity and Privacy Language for IT Procurements\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS provides templated language to use in IT procurements to ensure the security and privacy of information and information systems that CMS uses. This includes systems provided or managed by contractors or subcontractors on behalf of CMS. The ISSO may provide support to this process.\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/security-and-privacy-requirements-it-procurements\"\u003eLearn more about Security and Privacy Language for IT Procurements\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eTarget Life Cycle (TLC)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eCMS requires all new IT systems to follow the Target Life Cycle (TLC), a common framework for governing system development across the enterprise. The TLC accommodates various IT development methodologies while ensuring that systems meet all applicable legislative and policy requirements.\u0026nbsp;\u003c/p\u003e\u003cp\u003e(The TLC has replaced the former Expedited Life Cycle (XLC) as the official IT governance framework at CMS. If your current projects or contracts specify the use of XLC-related tools, templates, or reviews, you may continue using them.\u0026nbsp; You may also use fewer or alternative tools and templates, as long as you meet the minimum requirements outlined within the TLC.)\u003c/p\u003e\u003cp\u003eAs an ISSO, you will enter the TLC by filling out an intake form when:\u003c/p\u003e\u003cul\u003e\u003cli\u003eInitiate a new IT project\u003c/li\u003e\u003cli\u003eConduct an acquisition to support a new IT project\u003c/li\u003e\u003cli\u003eRequest new/increased funding to support an IT project\u0026nbsp;\u003c/li\u003e\u003cli\u003ePlan significant changes to an existing IT project\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eAfter submitting your form, the CMS IT Governance Team will help you meet TLC requirements. You can also contact the governance team via email: \u003ca href=\"mailto:IT_Governance@cms.hhs.gov\"\u003eIT_Governance@cms.hhs.gov\u003c/a\u003e\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/TLC\"\u003eLearn more about the TLC\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://share.cms.gov/Office/OIT/CIOCorner/Lists/Intake/NewForm.aspx\"\u003eFill out an intake form\u003c/a\u003e (requires CMS login)\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003e\u003cstrong\u003eResources external to CMS\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eHHS Policy for Information Security and Privacy Protection (IS2P)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe Department of Health and Human Services (HHS) is the parent organization for CMS. All of our policies and guidance are based on HHS-level documentation. The IS2P comprises HHS policies and procedures that ensure the secure collection, use, sharing, and storage of information that is both terrorism-related information and “protected information (PI)”.\u0026nbsp;\u003c/p\u003e\u003cp\u003eWhere possible, this document identifies existing HHS policies and procedures that meet the privacy requirements. Where necessary, however, this document also creates policies specific to the activities and resources that HHS requires.\u0026nbsp; The IS2P is one of the base documents from which CMS requirements are created. You can request a copy of this policy from the CISO team: \u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003eCISO@cms.hhs.gov\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eHHS Cybersecurity Library\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eSometimes CMS borrows policies and standards directly from HHS, our parent organization. You will sometimes need to access the HHS library of cybersecurity documents for your work.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://intranet.hhs.gov/security/index.html\"\u003eGo to the HHS library\u003c/a\u003e (requires login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNIST Special Publications\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eNIST Special Publications in the 800 series are of general interest to the computer security community, and these documents serve as the foundation for CMS security and privacy practices. Specifically helpful to ISSOs are the publications that contain detailed explanations of information security controls and the test cases used to assess them.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"\u003eNIST SP 800-53: Recommended Security Controls for Federal Information Systems\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final\"\u003eNIST SP 800-53A: Guide for Assessing the Security Controls in Federal Information Systems\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003ca href=\"/learn/national-institute-standards-and-technology-nist#nist-800-series-of-special-publications\"\u003eLearn more about NIST SP 800 series\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eNIST Computer Security Resource Center\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe National Institute of Standards and Technology (NIST) publishes helpful resources on computer, cyber, and information security and privacy. Explore publications, news, programs, and events that will help you expand your cybersecurity knowledge.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/\"\u003eVisit the NIST Resource Center\u003c/a\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eOMB Memoranda and Circulars\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eEvery year, the Office of Management and Budget (OMB) publishes a Memo with reporting instructions and guidance for FISMA, which can be useful to people with cybersecurity responsibilities at CMS. \u003ca href=\"https://www.whitehouse.gov/omb/information-for-agencies/memoranda/\"\u003eExplore OMB memos here\u003c/a\u003e.\u003c/p\u003e\u003cp\u003eThere are a number of OMB Circulars that provide general guidance on information security. Three of the most relevant are:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/omb/circulars_a130_a130appendix_iii\"\u003eA-130 - Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://www.osec.doc.gov/opog/privacy/Memorandums/OMB_Circular_A-123.pdf\"\u003eA-123 - Management's Responsibility for Internal Control\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://obamawhitehouse.archives.gov/omb/circulars_a127/\"\u003eA-127 - Financial Management Systems\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eOMB A-130 applies to all IT systems while A-123 and A-127 apply primarily to financial systems. ISSOs should be aware of these foundation documents and have a general understanding of their content. \u003ca href=\"https://www.whitehouse.gov/omb/information-for-agencies/circulars/\"\u003eExplore all OMB Circulars here\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho to contact\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eWhen you have a question or challenge, we are here to help! Here are key points of contact for situations you may face as an ISSO.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity or privacy incident\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eReport known or suspected security or privacy incidents involving CMS data to the CMS IT Service Desk by calling 410-786-2580 or 1-800-562-1963 or via e-mail to \u003ca href=\"mailto:CMS_IT_Service_Desk@cms.hhs.gov\"\u003eCMS_IT_Service_Desk@cms.hhs.gov\u003c/a\u003e.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSecurity or privacy questions\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eDo you have a question or concern related to CMS information security or privacy, and need a place to start? Send an email to the CISO Team at \u003ca href=\"mailto:CISO@cms.hhs.gov\"\u003eCISO@cms.hhs.gov\u003c/a\u003e regarding information security, or an email to \u003ca href=\"mailto:Privacy@cms.hhs.gov\"\u003eprivacy@cms.hhs.gov\u003c/a\u003e for questions regarding information privacy.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eISSO questions\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eIf you have questions about the ISSO role or other activities such as the ISSO Forum —or if you just want to hear from an ISSO — send an email to \u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eOversight and guidance\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe Cyber Risk Advisor (CRA) and Privacy Advisor are your ISPG support representatives. They help improve accountability and risk management by providing hands-on oversight to system cybersecurity and privacy risk.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eISSO community\u003c/strong\u003e\u003c/h3\u003e\u003ch4\u003e\u003cstrong\u003eCMS Cybersecurity Community Forum (C3F)\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThis monthly meeting is held for the benefit of the CMS security community, covering timely and relevant topics from ISPG speakers. It’s open to all CMS and contractor security professionals. Meeting details (location, time, video conferencing link) will be in the email invitation, which is sent monthly to everyone at CMS.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://confluenceent.cms.gov/pages/viewpage.action?spaceKey=IIP\u0026amp;title=CMS+ISSO+Forum\"\u003eSee past Forum videos and materials\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Journal\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eRead the ISSO Journal to stay updated on cybersecurity trends, learn about current events, and hear from other ISSOs. The Journal is distributed widely among CMS staff, and all cybersecurity professionals – both CMS and contractor staff – are invited to contribute! Contact us by email (\u003ca href=\"mailto:ISSO@cms.hhs.gov\"\u003eISSO@cms.hhs.gov\u003c/a\u003e) if you would like to write a post.\u003c/p\u003e\u003cp\u003e\u003ca href=\"https://confluenceent.cms.gov/pages/viewpage.action?spaceKey=IIP\u0026amp;title=CMS+ISSO+Journal\"\u003eRead the ISSO Journal\u003c/a\u003e (requires CMS login)\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eISSO Mentorship Program\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eThe mentorship program allows experienced ISSOs to support those who are newer to the role. For mentors, this is an opportunity to build leadership skills and strengthen the future of cybersecurity at CMS. For mentees, this allows you to build your knowledge faster and get hands-on support. The structure of the program is flexible — both ISSOs will decide what cadence and duration for meetings works for them.\u0026nbsp;\u003c/p\u003e\u003cp\u003eA mentorship usually lasts 6 months to a year. Your supervisor will need to approve your participation in the program.\u0026nbsp; Note that although the program is generally used by newer ISSOs, it is also available for existing ISSOs who want additional bootstrap help – for example, if they are dealing with an issue or project that is new to them. Mentorship is for these ISSOs, too!\u003c/p\u003e\u003cp\u003e\u003ca href=\"/learn/isso-mentorship-program\"\u003eLearn about the ISSO Mentorship Program\u003c/a\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eTraining\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003ePeople come to the ISSO role from many backgrounds, with differing experiences, so each may start at a different place. Broadly, ISSOs need to have both general cybersecurity knowledge and specific knowledge of how things operate at CMS. For new ISSOs, see the “Getting Started” section of this Handbook for tips on beginning your training journey.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eNICE code for ISSOs\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere is a Federal initiative to help train cybersecurity professionals. The \u003ca href=\"https://www.nist.gov/itl/applied-cybersecurity/nice\"\u003eNational Initiative for Cybersecurity Education\u003c/a\u003e (NICE) seeks to link appropriate training to cybersecurity roles by associating NICE “codes” with training opportunities. \u003cstrong\u003eAs an ISSO, your NICE code is OV‐MGT‐001\u003c/strong\u003e. Knowing this will help you find appropriate training for particular tasks or knowledge areas.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eTraining sources\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThere are many external sources – such as professional associations and training organizations – that can help you expand your cybersecurity knowledge and skills, but you can also get excellent free training that is provided by CMS and HHS. They are offered via the following platforms:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003ca href=\"http://www.cms.gov/cbt\"\u003eCMS Computer Based Training\u003c/a\u003e (CBT) - Free online training courses provided by CMS\u003c/li\u003e\u003cli\u003eCMS Cybersecurity Training Catalog - List of current training offerings and events (such as webinars) from CMS\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://confluenceent.cms.gov/display/IIP/ISSO+Training\"\u003eISSO Training Page\u003c/a\u003e - Collection of training resources in the ISPG Confluence environment that helps you navigate the training options available to you\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://ams.hhs.gov/amsLogin/SimpleLogin.jsp\"\u003eHHS Learning Management System\u003c/a\u003e\u0026nbsp; (LMS) - Free courses for federal employees (not contractors) provided through HHS to advance your core cybersecurity knowledge or prepare you for certifications\u003c/li\u003e\u003cli\u003e\u003ca href=\"https://fedvte.usalearning.gov/\"\u003eFederal Virtual Training Environment\u003c/a\u003e (FedVTE) - Another source of free training courses available to federal employees and contractors (similar to the LMS above).\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eTo help ISSOs focus on the most relevant training, below is a list of Basic, Intermediate, and Advanced courses that will help you grow in the specific skills needed for your role.\u003c/p\u003e\u003ch4\u003eBasic ISSO training\u003c/h4\u003e\u003cp\u003eThe courses recommended below provide both an introduction to cybersecurity in general and guidance on how these concepts are implemented at CMS. The courses listed in bold are the most important. You should consider some or all of the rest of the courses as your time permits. If possible, try to complete the bolded courses within your first two months as an ISSO. There is no cost to take these courses. Note: HHS LMS is only available to federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eISSO Fundamentals\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eWorking With CFACTS\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eClassroom / Remote\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eAll About the CMS Acceptable Risk Safeguards (ARS 5.1)\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003ePrivacy and Awareness Training\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eExecutive’s Guide to Security: Protecting Your Information\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Awareness: Getting Started with Security Foundations, Information Security Fundamentals, and Key Security Terms\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompliance Expert: IT Security - Phishing, Safeguarding Mobile Devices, and Privacy \u0026amp; Information Security (The Basics)\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity 101: Auditing \u0026amp; Incident Response and Session \u0026amp; Risk Management\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003eIntermediate ISSO training\u003c/h4\u003e\u003cp\u003eThe courses recommended below will build on your initial knowledge. As before, you should start with the courses listed in bold, or on topics that have immediate importance to you. There is no cost to take these courses. Note: HHS LMS is only available for federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eNavigating New Cybersecurity and Privacy Policies and Procedures\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eHow Hackers Hack and How to Protect Yourself\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eIncident Response at CMS\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCMS Privacy Incident Response: Quick Guide for Business Owners\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Race\u003c/td\u003e\u003ctd\u003eCBT\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eFundamentals of Cyber Risk Management\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eFoundations of Incident Management\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompliance Expert: IT Security - Phishing\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCybersecurity Audits\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eImplementation of Security Controls\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003eAdvanced ISSO training\u003c/h4\u003e\u003cp\u003eThe advanced courses recommended below will help you gain a deeper understanding of the cybersecurity issues that you have been working with. They may also be appropriate to take earlier if you entered the ISSO role with a good basic understanding of both CMS operations and cybersecurity in general. There is no cost to take these courses.\u0026nbsp; Note: HHS LMS is only available for federal employees.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eCourse\u003c/th\u003e\u003cth\u003eSource\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eEmerging Cyber Security Threats\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecuring Infrastructure Devices\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSecuring the Network Perimeter\u003c/td\u003e\u003ctd\u003eFedVTE\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Computing Fundamentals: Cloud Security\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Architecture\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Security\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eCloud Data Platforms\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCloud Security Fundamentals\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA A+: Security Fundamentals\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u003cstrong\u003eEncryption and Malware\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA Server+: Network Security Protocols\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCompTIA Cloud+\u003c/td\u003e\u003ctd\u003eLMS\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e"])</script><script>self.__next_f.push([1,"2c7:{\"value\":\"$2c8\",\"format\":\"body_text\",\"processed\":\"$2c9\",\"summary\":\"\"}\n2cc:[]\n2cb:{\"uri\":\"entity:node/376\",\"title\":\"Information System Security Officer (ISSO)\",\"options\":\"$2cc\",\"url\":\"/ispg/information-system-security-officer-isso\"}\n2ce:[]\n2cd:{\"uri\":\"entity:node/721\",\"title\":\"ISSO Appointment Letter\",\"options\":\"$2ce\",\"url\":\"/learn/isso-appointment-letter\"}\n2d0:[]\n2cf:{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security and Privacy Policy (IS2P2)\",\"options\":\"$2d0\",\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"}\n2ca:[\"$2cb\",\"$2cd\",\"$2cf\"]\n2d1:{\"value\":\"Guidance to help ISSOs in their daily work, including role descriptions, resources, points of contact, and training\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eGuidance to help ISSOs in their daily work, including role descriptions, resources, points of contact, and training\u003c/p\u003e\\n\"}\n2c5:{\"drupal_internal__nid\":366,\"drupal_internal__vid\":5712,\"langcode\":\"en\",\"revision_timestamp\":\"2024-07-25T14:57:26+00:00\",\"status\":true,\"title\":\"CMS Information System Security Officer (ISSO) Handbook\",\"created\":\"2022-08-29T16:40:17+00:00\",\"changed\":\"2024-07-25T14:57:26+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":\"$2c6\",\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":\"$2c7\",\"field_contact_email\":\"ISSO@cms.hhs.gov\",\"field_contact_name\":\"ISSO Support Team\",\"field_last_reviewed\":\"2024-07-15\",\"field_related_resources\":\"$2ca\",\"field_short_description\":\"$2d1\"}\n2d5:{\"drupal_internal__target_id\":\"library\"}\n2d4:{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":\"$2d5\"}\n2d7:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/node_type?resourceVersion=id%3A5712\"}\n2d8:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/node_type?resourceVersio"])</script><script>self.__next_f.push([1,"n=id%3A5712\"}\n2d6:{\"related\":\"$2d7\",\"self\":\"$2d8\"}\n2d3:{\"data\":\"$2d4\",\"links\":\"$2d6\"}\n2db:{\"drupal_internal__target_id\":6}\n2da:{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":\"$2db\"}\n2dd:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/revision_uid?resourceVersion=id%3A5712\"}\n2de:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/revision_uid?resourceVersion=id%3A5712\"}\n2dc:{\"related\":\"$2dd\",\"self\":\"$2de\"}\n2d9:{\"data\":\"$2da\",\"links\":\"$2dc\"}\n2e1:{\"drupal_internal__target_id\":26}\n2e0:{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":\"$2e1\"}\n2e3:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/uid?resourceVersion=id%3A5712\"}\n2e4:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/uid?resourceVersion=id%3A5712\"}\n2e2:{\"related\":\"$2e3\",\"self\":\"$2e4\"}\n2df:{\"data\":\"$2e0\",\"links\":\"$2e2\"}\n2e7:{\"drupal_internal__target_id\":91}\n2e6:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":\"$2e7\"}\n2e9:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/field_resource_type?resourceVersion=id%3A5712\"}\n2ea:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/field_resource_type?resourceVersion=id%3A5712\"}\n2e8:{\"related\":\"$2e9\",\"self\":\"$2ea\"}\n2e5:{\"data\":\"$2e6\",\"links\":\"$2e8\"}\n2ee:{\"drupal_internal__target_id\":61}\n2ed:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":\"$2ee\"}\n2ec:[\"$2ed\"]\n2f0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/field_roles?resourceVersion=id%3A5712\"}\n2f1:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/field_roles?resourceVersion=id%3A5712\"}\n2ef:{\"related\":\"$2f0\",\"self\":\"$2f1\"}\n2eb:{\"data\":\"$2ec\",\"links\":"])</script><script>self.__next_f.push([1,"\"$2ef\"}\n2f5:{\"drupal_internal__target_id\":56}\n2f4:{\"type\":\"taxonomy_term--topics\",\"id\":\"8b8ffea0-3b0b-404d-8442-7f3a4602482d\",\"meta\":\"$2f5\"}\n2f3:[\"$2f4\"]\n2f7:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/field_topics?resourceVersion=id%3A5712\"}\n2f8:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/field_topics?resourceVersion=id%3A5712\"}\n2f6:{\"related\":\"$2f7\",\"self\":\"$2f8\"}\n2f2:{\"data\":\"$2f3\",\"links\":\"$2f6\"}\n2d2:{\"node_type\":\"$2d3\",\"revision_uid\":\"$2d9\",\"uid\":\"$2df\",\"field_resource_type\":\"$2e5\",\"field_roles\":\"$2eb\",\"field_topics\":\"$2f2\"}\n2c2:{\"type\":\"node--library\",\"id\":\"fa2107f3-5c24-458b-b589-6c85321f2015\",\"links\":\"$2c3\",\"attributes\":\"$2c5\",\"relationships\":\"$2d2\"}\n"])</script><script>self.__next_f.push([1,"5:[\"$\",\"$L17\",null,{\"content\":{\"data\":{\"type\":\"node--explainer\",\"id\":\"e58a0846-aa6a-43bf-a0a8-a40cfafe0675\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675?resourceVersion=id%3A5970\"}},\"attributes\":{\"drupal_internal__nid\":681,\"drupal_internal__vid\":5970,\"langcode\":\"en\",\"revision_timestamp\":\"2024-11-21T20:30:37+00:00\",\"status\":true,\"title\":\"CMS Security and Privacy Handbooks\",\"created\":\"2023-02-04T16:50:42+00:00\",\"changed\":\"2024-11-21T20:30:37+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/learn/cms-security-and-privacy-handbooks\",\"pid\":671,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":null,\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_short_description\":{\"value\":\"Procedures to help CMS staff and contractors implement federal policies and standards for information security and privacy\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eProcedures to help CMS staff and contractors implement federal policies and standards for information security and privacy\u003c/p\u003e\\n\"},\"field_slack_channel\":[\"#ispg-sec_privacy-policy\"]},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"meta\":{\"drupal_internal__target_id\":\"explainer\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/node_type?resourceVersion=id%3A5970\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/relationships/node_type?resourceVersion=id%3A5970\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":{\"drupal_internal__target_id\":6}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/revision_uid?resourceVersion=id%3A5970\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/relationships/revision_uid?resourceVersion=id%3A5970\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":{\"drupal_internal__target_id\":6}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/uid?resourceVersion=id%3A5970\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/relationships/uid?resourceVersion=id%3A5970\"}}},\"field_page_section\":{\"data\":[{\"type\":\"paragraph--page_section\",\"id\":\"6348291e-48d1-4a0e-9a57-ac86d40af43e\",\"meta\":{\"target_revision_id\":19550,\"drupal_internal__target_id\":556}},{\"type\":\"paragraph--page_section\",\"id\":\"f5048b9a-b22a-4e67-abde-e964ff928b22\",\"meta\":{\"target_revision_id\":19551,\"drupal_internal__target_id\":1031}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/field_page_section?resourceVersion=id%3A5970\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/relationships/field_page_section?resourceVersion=id%3A5970\"}}},\"field_related_collection\":{\"data\":[{\"type\":\"paragraph--internal_link\",\"id\":\"0f74c41a-2461-4cf5-b11e-ff7ce0b96f66\",\"meta\":{\"target_revision_id\":19552,\"drupal_internal__target_id\":566}},{\"type\":\"paragraph--internal_link\",\"id\":\"fe6656d7-9b88-4a4c-a27f-e41c610ab068\",\"meta\":{\"target_revision_id\":19553,\"drupal_internal__target_id\":571}},{\"type\":\"paragraph--internal_link\",\"id\":\"80d4e83c-5a1f-466b-9518-5400af425d7f\",\"meta\":{\"target_revision_id\":19554,\"drupal_internal__target_id\":576}},{\"type\":\"paragraph--internal_link\",\"id\":\"9967f006-5e08-4568-b636-63e8e8050a8f\",\"meta\":{\"target_revision_id\":19555,\"drupal_internal__target_id\":2776}},{\"type\":\"paragraph--internal_link\",\"id\":\"e0709a54-90c1-4f0d-b02a-5e8dce6acc17\",\"meta\":{\"target_revision_id\":19556,\"drupal_internal__target_id\":1871}},{\"type\":\"paragraph--internal_link\",\"id\":\"9c79715c-bf72-4433-9d27-f6a64a297c18\",\"meta\":{\"target_revision_id\":19557,\"drupal_internal__target_id\":3512}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/field_related_collection?resourceVersion=id%3A5970\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/relationships/field_related_collection?resourceVersion=id%3A5970\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"meta\":{\"drupal_internal__target_id\":131}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/field_resource_type?resourceVersion=id%3A5970\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/relationships/field_resource_type?resourceVersion=id%3A5970\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":{\"drupal_internal__target_id\":66}},{\"type\":\"taxonomy_term--roles\",\"id\":\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\",\"meta\":{\"drupal_internal__target_id\":81}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}},{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"meta\":{\"drupal_internal__target_id\":71}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/field_roles?resourceVersion=id%3A5970\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/relationships/field_roles?resourceVersion=id%3A5970\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":{\"drupal_internal__target_id\":16}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/field_topics?resourceVersion=id%3A5970\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/e58a0846-aa6a-43bf-a0a8-a40cfafe0675/relationships/field_topics?resourceVersion=id%3A5970\"}}}}},\"included\":[{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node_type/node_type/d185e460-4998-4d2b-85cb-b04f304dfb1b\"}},\"attributes\":{\"langcode\":\"en\",\"status\":true,\"dependencies\":{\"module\":[\"menu_ui\",\"scheduler\"]},\"third_party_settings\":{\"menu_ui\":{\"available_menus\":[],\"parent\":\"\"},\"scheduler\":{\"expand_fieldset\":\"when_required\",\"fields_display_mode\":\"vertical_tab\",\"publish_enable\":false,\"publish_past_date\":\"error\",\"publish_past_date_created\":false,\"publish_required\":false,\"publish_revision\":false,\"publish_touch\":false,\"show_message_after_update\":true,\"unpublish_enable\":false,\"unpublish_required\":false,\"unpublish_revision\":false}},\"name\":\"Explainer page\",\"drupal_internal__type\":\"explainer\",\"description\":\"Use \u003ci\u003eExplainer pages\u003c/i\u003e to provide general information in plain language about a policy, program, tool, service, or task related to security and privacy at CMS.\",\"help\":null,\"new_revision\":true,\"preview_mode\":1,\"display_submitted\":true}},{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/user/user/e352e203-fe9c-47ba-af75-2c7f8302fca8\"}},\"attributes\":{\"display_name\":\"mburgess\"}},{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22?resourceVersion=id%3A131\"}},\"attributes\":{\"drupal_internal__tid\":131,\"drupal_internal__revision_id\":131,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:13:33+00:00\",\"status\":true,\"name\":\"General Information\",\"description\":null,\"weight\":2,\"changed\":\"2023-03-10T19:04:03+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"3a0127c4-ee06-41ed-8239-f796f6d78eb3\",\"meta\":{\"drupal_internal__target_id\":\"resource_type\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/vid?resourceVersion=id%3A131\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/vid?resourceVersion=id%3A131\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/revision_user?resourceVersion=id%3A131\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/revision_user?resourceVersion=id%3A131\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--resource_type\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/parent?resourceVersion=id%3A131\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/parent?resourceVersion=id%3A131\"}}}}},{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5?resourceVersion=id%3A66\"}},\"attributes\":{\"drupal_internal__tid\":66,\"drupal_internal__revision_id\":66,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:26+00:00\",\"status\":true,\"name\":\"Cyber Risk Advisor (CRA)\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:26+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":{\"drupal_internal__target_id\":\"roles\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/vid?resourceVersion=id%3A66\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/relationships/vid?resourceVersion=id%3A66\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/revision_user?resourceVersion=id%3A66\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/relationships/revision_user?resourceVersion=id%3A66\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/parent?resourceVersion=id%3A66\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/9d999ae3-b43c-45fb-973e-dffe50c27da5/relationships/parent?resourceVersion=id%3A66\"}}}}},{\"type\":\"taxonomy_term--roles\",\"id\":\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26?resourceVersion=id%3A81\"}},\"attributes\":{\"drupal_internal__tid\":81,\"drupal_internal__revision_id\":81,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:09:11+00:00\",\"status\":true,\"name\":\"Data Guardian\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:09:11+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":{\"drupal_internal__target_id\":\"roles\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/vid?resourceVersion=id%3A81\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/relationships/vid?resourceVersion=id%3A81\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/revision_user?resourceVersion=id%3A81\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/relationships/revision_user?resourceVersion=id%3A81\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/parent?resourceVersion=id%3A81\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/a2b33f6a-8172-4862-9c0e-6e5076b6cf26/relationships/parent?resourceVersion=id%3A81\"}}}}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab?resourceVersion=id%3A61\"}},\"attributes\":{\"drupal_internal__tid\":61,\"drupal_internal__revision_id\":61,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:12+00:00\",\"status\":true,\"name\":\"Information System Security Officer (ISSO)\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:12+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":{\"drupal_internal__target_id\":\"roles\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/vid?resourceVersion=id%3A61\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/vid?resourceVersion=id%3A61\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/revision_user?resourceVersion=id%3A61\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/revision_user?resourceVersion=id%3A61\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/parent?resourceVersion=id%3A61\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/parent?resourceVersion=id%3A61\"}}}}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34?resourceVersion=id%3A76\"}},\"attributes\":{\"drupal_internal__tid\":76,\"drupal_internal__revision_id\":76,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:55+00:00\",\"status\":true,\"name\":\"System / Business Owner\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:55+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":{\"drupal_internal__target_id\":\"roles\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/vid?resourceVersion=id%3A76\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/vid?resourceVersion=id%3A76\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/revision_user?resourceVersion=id%3A76\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/revision_user?resourceVersion=id%3A76\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/parent?resourceVersion=id%3A76\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/parent?resourceVersion=id%3A76\"}}}}},{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e?resourceVersion=id%3A71\"}},\"attributes\":{\"drupal_internal__tid\":71,\"drupal_internal__revision_id\":71,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:42+00:00\",\"status\":true,\"name\":\"System Teams\",\"description\":null,\"weight\":0,\"changed\":\"2024-08-02T21:29:47+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":{\"drupal_internal__target_id\":\"roles\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/vid?resourceVersion=id%3A71\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/vid?resourceVersion=id%3A71\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/revision_user?resourceVersion=id%3A71\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/revision_user?resourceVersion=id%3A71\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/parent?resourceVersion=id%3A71\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/parent?resourceVersion=id%3A71\"}}}}},{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0?resourceVersion=id%3A16\"}},\"attributes\":{\"drupal_internal__tid\":16,\"drupal_internal__revision_id\":16,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:05:20+00:00\",\"status\":true,\"name\":\"CMS Policy \u0026 Guidance\",\"description\":null,\"weight\":2,\"changed\":\"2023-03-10T19:04:22+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"73f89dec-123f-4c8c-9a97-d025a2b0e5cf\",\"meta\":{\"drupal_internal__target_id\":\"topics\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/vid?resourceVersion=id%3A16\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/relationships/vid?resourceVersion=id%3A16\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/revision_user?resourceVersion=id%3A16\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/relationships/revision_user?resourceVersion=id%3A16\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/parent?resourceVersion=id%3A16\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/c12221c3-2c7e-4eb0-903f-0470aad63bf0/relationships/parent?resourceVersion=id%3A16\"}}}}},{\"type\":\"paragraph--page_section\",\"id\":\"6348291e-48d1-4a0e-9a57-ac86d40af43e\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e?resourceVersion=id%3A19550\"}},\"attributes\":{\"drupal_internal__id\":556,\"drupal_internal__revision_id\":19550,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-04T16:55:18+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_page_section\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true,\"field_text_block\":{\"value\":\"$18\",\"format\":\"body_text\",\"processed\":\"$19\"}},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"57f3f40a-8120-4393-b881-a5758f9fb30d\",\"meta\":{\"drupal_internal__target_id\":\"page_section\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e/paragraph_type?resourceVersion=id%3A19550\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e/relationships/paragraph_type?resourceVersion=id%3A19550\"}}},\"field_specialty_item\":{\"data\":{\"type\":\"paragraph--call_out_box\",\"id\":\"8b6ef8b3-acd0-47f9-8050-9c68b8c24ada\",\"meta\":{\"target_revision_id\":19549,\"drupal_internal__target_id\":3390}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e/field_specialty_item?resourceVersion=id%3A19550\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/6348291e-48d1-4a0e-9a57-ac86d40af43e/relationships/field_specialty_item?resourceVersion=id%3A19550\"}}}}},{\"type\":\"paragraph--page_section\",\"id\":\"f5048b9a-b22a-4e67-abde-e964ff928b22\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22?resourceVersion=id%3A19551\"}},\"attributes\":{\"drupal_internal__id\":1031,\"drupal_internal__revision_id\":19551,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-09T15:43:03+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_page_section\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true,\"field_text_block\":{\"value\":\"$1a\",\"format\":\"body_text\",\"processed\":\"$1b\"}},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"57f3f40a-8120-4393-b881-a5758f9fb30d\",\"meta\":{\"drupal_internal__target_id\":\"page_section\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22/paragraph_type?resourceVersion=id%3A19551\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22/relationships/paragraph_type?resourceVersion=id%3A19551\"}}},\"field_specialty_item\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22/field_specialty_item?resourceVersion=id%3A19551\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/f5048b9a-b22a-4e67-abde-e964ff928b22/relationships/field_specialty_item?resourceVersion=id%3A19551\"}}}}},{\"type\":\"paragraph--call_out_box\",\"id\":\"8b6ef8b3-acd0-47f9-8050-9c68b8c24ada\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/call_out_box/8b6ef8b3-acd0-47f9-8050-9c68b8c24ada?resourceVersion=id%3A19549\"}},\"attributes\":{\"drupal_internal__id\":3390,\"drupal_internal__revision_id\":19549,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-07-08T15:06:58+00:00\",\"parent_id\":\"556\",\"parent_type\":\"paragraph\",\"parent_field_name\":\"field_specialty_item\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true,\"field_call_out_link\":{\"uri\":\"https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks\",\"title\":\"\",\"options\":[],\"url\":\"https://security.cms.gov/search?ispg%5BrefinementList%5D%5Bresource_type%5D%5B0%5D=Handbooks\"},\"field_call_out_link_text\":\"Go to the Handbooks\",\"field_call_out_text\":{\"value\":\"Using the Search function on the ISPG \\\"CyberGeek\\\" website, you can search and filter to find CMS Security and Privacy Handbooks on a variety of topics.\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eUsing the Search function on the ISPG \u0026quot;CyberGeek\u0026quot; website, you can search and filter to find CMS Security and Privacy Handbooks on a variety of topics.\u003c/p\u003e\\n\"},\"field_header\":\"See all Security and Privacy Handbooks\"},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"a1d0a205-c6c9-4816-b701-4763d05de8e8\",\"meta\":{\"drupal_internal__target_id\":\"call_out_box\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/call_out_box/8b6ef8b3-acd0-47f9-8050-9c68b8c24ada/paragraph_type?resourceVersion=id%3A19549\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/call_out_box/8b6ef8b3-acd0-47f9-8050-9c68b8c24ada/relationships/paragraph_type?resourceVersion=id%3A19549\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"0f74c41a-2461-4cf5-b11e-ff7ce0b96f66\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66?resourceVersion=id%3A19552\"}},\"attributes\":{\"drupal_internal__id\":566,\"drupal_internal__revision_id\":19552,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-07T16:51:17+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66/paragraph_type?resourceVersion=id%3A19552\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66/relationships/paragraph_type?resourceVersion=id%3A19552\"}}},\"field_link\":{\"data\":{\"type\":\"node--library\",\"id\":\"4c71fa83-e15c-4187-a479-696657ea5e15\",\"meta\":{\"drupal_internal__target_id\":1126}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66/field_link?resourceVersion=id%3A19552\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/0f74c41a-2461-4cf5-b11e-ff7ce0b96f66/relationships/field_link?resourceVersion=id%3A19552\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"fe6656d7-9b88-4a4c-a27f-e41c610ab068\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068?resourceVersion=id%3A19553\"}},\"attributes\":{\"drupal_internal__id\":571,\"drupal_internal__revision_id\":19553,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-07T16:50:30+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068/paragraph_type?resourceVersion=id%3A19553\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068/relationships/paragraph_type?resourceVersion=id%3A19553\"}}},\"field_link\":{\"data\":{\"type\":\"node--library\",\"id\":\"ddb65a30-0e50-44c7-a6bd-084b9a7e6f06\",\"meta\":{\"drupal_internal__target_id\":421}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068/field_link?resourceVersion=id%3A19553\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/fe6656d7-9b88-4a4c-a27f-e41c610ab068/relationships/field_link?resourceVersion=id%3A19553\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"80d4e83c-5a1f-466b-9518-5400af425d7f\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b-9518-5400af425d7f?resourceVersion=id%3A19554\"}},\"attributes\":{\"drupal_internal__id\":576,\"drupal_internal__revision_id\":19554,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-07T16:50:55+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b-9518-5400af425d7f/paragraph_type?resourceVersion=id%3A19554\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b-9518-5400af425d7f/relationships/paragraph_type?resourceVersion=id%3A19554\"}}},\"field_link\":{\"data\":{\"type\":\"node--library\",\"id\":\"4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e\",\"meta\":{\"drupal_internal__target_id\":621}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b-9518-5400af425d7f/field_link?resourceVersion=id%3A19554\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/80d4e83c-5a1f-466b-9518-5400af425d7f/relationships/field_link?resourceVersion=id%3A19554\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"9967f006-5e08-4568-b636-63e8e8050a8f\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f?resourceVersion=id%3A19555\"}},\"attributes\":{\"drupal_internal__id\":2776,\"drupal_internal__revision_id\":19555,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-04-05T14:07:45+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f/paragraph_type?resourceVersion=id%3A19555\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f/relationships/paragraph_type?resourceVersion=id%3A19555\"}}},\"field_link\":{\"data\":{\"type\":\"node--library\",\"id\":\"cba2b00b-3f53-42bd-8a60-f175e1d47a0a\",\"meta\":{\"drupal_internal__target_id\":401}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f/field_link?resourceVersion=id%3A19555\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9967f006-5e08-4568-b636-63e8e8050a8f/relationships/field_link?resourceVersion=id%3A19555\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"e0709a54-90c1-4f0d-b02a-5e8dce6acc17\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17?resourceVersion=id%3A19556\"}},\"attributes\":{\"drupal_internal__id\":1871,\"drupal_internal__revision_id\":19556,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-15T19:23:49+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17/paragraph_type?resourceVersion=id%3A19556\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17/relationships/paragraph_type?resourceVersion=id%3A19556\"}}},\"field_link\":{\"data\":{\"type\":\"node--library\",\"id\":\"596fc706-aa93-4b33-84a6-e648cf6c563d\",\"meta\":{\"drupal_internal__target_id\":1141}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17/field_link?resourceVersion=id%3A19556\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/e0709a54-90c1-4f0d-b02a-5e8dce6acc17/relationships/field_link?resourceVersion=id%3A19556\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"9c79715c-bf72-4433-9d27-f6a64a297c18\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18?resourceVersion=id%3A19557\"}},\"attributes\":{\"drupal_internal__id\":3512,\"drupal_internal__revision_id\":19557,\"langcode\":\"en\",\"status\":true,\"created\":\"2024-07-02T15:20:38+00:00\",\"parent_id\":\"681\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18/paragraph_type?resourceVersion=id%3A19557\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18/relationships/paragraph_type?resourceVersion=id%3A19557\"}}},\"field_link\":{\"data\":{\"type\":\"node--library\",\"id\":\"fa2107f3-5c24-458b-b589-6c85321f2015\",\"meta\":{\"drupal_internal__target_id\":366}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18/field_link?resourceVersion=id%3A19557\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9c79715c-bf72-4433-9d27-f6a64a297c18/relationships/field_link?resourceVersion=id%3A19557\"}}}}},{\"type\":\"node--library\",\"id\":\"4c71fa83-e15c-4187-a479-696657ea5e15\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15?resourceVersion=id%3A6181\"}},\"attributes\":{\"drupal_internal__nid\":1126,\"drupal_internal__vid\":6181,\"langcode\":\"en\",\"revision_timestamp\":\"2025-01-22T14:43:00+00:00\",\"status\":true,\"title\":\"CMS Access Control Handbook\",\"created\":\"2023-06-29T13:37:08+00:00\",\"changed\":\"2025-01-22T14:43:00+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/policy-guidance/cms-access-control-handbook\",\"pid\":981,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":{\"value\":\"$1c\",\"format\":\"body_text\",\"processed\":\"$1d\",\"summary\":\"\"},\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_last_reviewed\":\"2023-06-20\",\"field_related_resources\":[{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security \u0026 Privacy Policy (IS2P2) \",\"options\":[],\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"},{\"uri\":\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\",\"title\":\"NIST Security and Privacy Controls for Information Systems and Organizations\",\"options\":[],\"url\":\"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final\"},{\"uri\":\"entity:node/1112\",\"title\":\"Security Operations\",\"options\":[],\"url\":\"/ispg/security-operations\"}],\"field_short_description\":{\"value\":\"A guide that provides an overview of the policies, procedures, and processes needed to implement security requirements for the Access Control (AC) family\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eA guide that provides an overview of the policies, procedures, and processes needed to implement security requirements for the Access Control (AC) family\u003c/p\u003e\\n\"}},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":{\"drupal_internal__target_id\":\"library\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/node_type?resourceVersion=id%3A6181\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/node_type?resourceVersion=id%3A6181\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":{\"drupal_internal__target_id\":6}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/revision_uid?resourceVersion=id%3A6181\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/revision_uid?resourceVersion=id%3A6181\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":{\"drupal_internal__target_id\":26}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/uid?resourceVersion=id%3A6181\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/uid?resourceVersion=id%3A6181\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":{\"drupal_internal__target_id\":91}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/field_resource_type?resourceVersion=id%3A6181\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/field_resource_type?resourceVersion=id%3A6181\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":{\"drupal_internal__target_id\":66}},{\"type\":\"taxonomy_term--roles\",\"id\":\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\",\"meta\":{\"drupal_internal__target_id\":81}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}},{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"meta\":{\"drupal_internal__target_id\":71}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/field_roles?resourceVersion=id%3A6181\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/field_roles?resourceVersion=id%3A6181\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":{\"drupal_internal__target_id\":16}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/field_topics?resourceVersion=id%3A6181\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4c71fa83-e15c-4187-a479-696657ea5e15/relationships/field_topics?resourceVersion=id%3A6181\"}}}}},{\"type\":\"node--library\",\"id\":\"ddb65a30-0e50-44c7-a6bd-084b9a7e6f06\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06?resourceVersion=id%3A5561\"}},\"attributes\":{\"drupal_internal__nid\":421,\"drupal_internal__vid\":5561,\"langcode\":\"en\",\"revision_timestamp\":\"2024-06-07T20:11:35+00:00\",\"status\":true,\"title\":\"CMS Privacy Impact Assessment (PIA) Handbook\",\"created\":\"2022-08-29T17:13:40+00:00\",\"changed\":\"2024-06-06T17:47:05+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/policy-guidance/cms-privacy-impact-assessment-pia-handbook\",\"pid\":411,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":{\"value\":\"$1e\",\"format\":\"body_text\",\"processed\":\"$1f\",\"summary\":\"\"},\"field_contact_email\":\"privacy@cms.hhs.gov\",\"field_contact_name\":\"Privacy Office\",\"field_last_reviewed\":\"2023-01-20\",\"field_related_resources\":[{\"uri\":\"entity:node/206\",\"title\":\"Authorization to Operate (ATO) \",\"options\":[],\"url\":\"/learn/authorization-operate-ato\"},{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security and Privacy Policy (IS2P2)\",\"options\":[],\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"},{\"uri\":\"https://www.hhs.gov/pia/index.html\",\"title\":\"HHS Privacy Impact Assessment (PIA) information\",\"options\":[],\"url\":\"https://www.hhs.gov/pia/index.html\"}],\"field_short_description\":{\"value\":\"Information, tips, and tricks for writing your Privacy Impact Assessment (PIA) concisely and correctly\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eInformation, tips, and tricks for writing your Privacy Impact Assessment (PIA) concisely and correctly\u003c/p\u003e\\n\"}},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":{\"drupal_internal__target_id\":\"library\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/node_type?resourceVersion=id%3A5561\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/node_type?resourceVersion=id%3A5561\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"a54cc91d-d38c-4158-9cf3-d7bcda34fc84\",\"meta\":{\"drupal_internal__target_id\":110}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/revision_uid?resourceVersion=id%3A5561\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/revision_uid?resourceVersion=id%3A5561\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":{\"drupal_internal__target_id\":26}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/uid?resourceVersion=id%3A5561\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/uid?resourceVersion=id%3A5561\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":{\"drupal_internal__target_id\":91}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/field_resource_type?resourceVersion=id%3A5561\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/field_resource_type?resourceVersion=id%3A5561\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":{\"drupal_internal__target_id\":66}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/field_roles?resourceVersion=id%3A5561\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/field_roles?resourceVersion=id%3A5561\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":{\"drupal_internal__target_id\":16}},{\"type\":\"taxonomy_term--topics\",\"id\":\"d5e2c0ee-04cb-493b-9338-c97adf0e8adf\",\"meta\":{\"drupal_internal__target_id\":31}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/field_topics?resourceVersion=id%3A5561\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/ddb65a30-0e50-44c7-a6bd-084b9a7e6f06/relationships/field_topics?resourceVersion=id%3A5561\"}}}}},{\"type\":\"node--library\",\"id\":\"4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e?resourceVersion=id%3A4913\"}},\"attributes\":{\"drupal_internal__nid\":621,\"drupal_internal__vid\":4913,\"langcode\":\"en\",\"revision_timestamp\":\"2023-08-23T18:12:45+00:00\",\"status\":true,\"title\":\"CMS Breach Response Handbook\",\"created\":\"2022-12-30T21:49:21+00:00\",\"changed\":\"2023-08-23T18:12:45+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":null,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/policy-guidance/cms-breach-response-handbook\",\"pid\":611,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":{\"value\":\"$20\",\"format\":\"body_text\",\"processed\":\"$21\",\"summary\":\"\"},\"field_contact_email\":\"IMT@cms.hhs.gov\",\"field_contact_name\":\"Incident Management Team\",\"field_last_reviewed\":\"2022-11-07\",\"field_related_resources\":[{\"uri\":\"entity:node/696\",\"title\":\"Breach Response \",\"options\":[],\"url\":\"/learn/breach-response\"},{\"uri\":\"entity:node/701\",\"title\":\"CMS Breach Analysis Team (BAT) Handbook \",\"options\":[],\"url\":\"/policy-guidance/cms-breach-analysis-team-bat-handbook\"}],\"field_short_description\":{\"value\":\"Procedures for handling a breach of sensitive data at CMS, including roles, responsibilities, and reporting requirements\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eProcedures for handling a breach of sensitive data at CMS, including roles, responsibilities, and reporting requirements\u003c/p\u003e\\n\"}},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":{\"drupal_internal__target_id\":\"library\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/node_type?resourceVersion=id%3A4913\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/node_type?resourceVersion=id%3A4913\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"663db243-0ec9-4d3f-9589-5a0ed308fbbc\",\"meta\":{\"drupal_internal__target_id\":36}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/revision_uid?resourceVersion=id%3A4913\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/revision_uid?resourceVersion=id%3A4913\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":{\"drupal_internal__target_id\":6}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/uid?resourceVersion=id%3A4913\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/uid?resourceVersion=id%3A4913\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":{\"drupal_internal__target_id\":91}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/field_resource_type?resourceVersion=id%3A4913\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/field_resource_type?resourceVersion=id%3A4913\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":{\"drupal_internal__target_id\":66}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/field_roles?resourceVersion=id%3A4913\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/field_roles?resourceVersion=id%3A4913\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"d5e2c0ee-04cb-493b-9338-c97adf0e8adf\",\"meta\":{\"drupal_internal__target_id\":31}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/field_topics?resourceVersion=id%3A4913\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e/relationships/field_topics?resourceVersion=id%3A4913\"}}}}},{\"type\":\"node--library\",\"id\":\"cba2b00b-3f53-42bd-8a60-f175e1d47a0a\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a?resourceVersion=id%3A5866\"}},\"attributes\":{\"drupal_internal__nid\":401,\"drupal_internal__vid\":5866,\"langcode\":\"en\",\"revision_timestamp\":\"2024-08-13T19:41:02+00:00\",\"status\":true,\"title\":\"CMS Plan of Action and Milestones (POA\u0026M) Handbook\",\"created\":\"2022-08-29T16:59:47+00:00\",\"changed\":\"2024-08-05T15:55:04+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/policy-guidance/cms-plan-action-and-milestones-poam-handbook\",\"pid\":391,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":{\"value\":\"$22\",\"format\":\"body_text\",\"processed\":\"$23\",\"summary\":\"\"},\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_last_reviewed\":\"2023-04-05\",\"field_related_resources\":[{\"uri\":\"entity:node/561\",\"title\":\"CMS System Audits \",\"options\":[],\"url\":\"/learn/system-audits\"},{\"uri\":\"https://intranet.hhs.gov/document/standard-plans-action-and-milestones-poam-management-and-reporting\",\"title\":\"HHS Plan of Action and Milestones (POA\u0026M) guidance \",\"options\":[],\"url\":\"https://intranet.hhs.gov/document/standard-plans-action-and-milestones-poam-management-and-reporting\"},{\"uri\":\"entity:node/201\",\"title\":\"Cybersecurity and Risk Assessment Program (CSRAP)\",\"options\":[],\"url\":\"/learn/cybersecurity-risk-assessment-program-csrap\"}],\"field_short_description\":{\"value\":\"A complete guide to creating, managing, and closing your system’s POA\u0026M\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eA complete guide to creating, managing, and closing your system’s POA\u0026amp;M\u003c/p\u003e\\n\"}},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":{\"drupal_internal__target_id\":\"library\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/node_type?resourceVersion=id%3A5866\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/node_type?resourceVersion=id%3A5866\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"a54cc91d-d38c-4158-9cf3-d7bcda34fc84\",\"meta\":{\"drupal_internal__target_id\":110}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/revision_uid?resourceVersion=id%3A5866\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/revision_uid?resourceVersion=id%3A5866\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":{\"drupal_internal__target_id\":26}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/uid?resourceVersion=id%3A5866\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/uid?resourceVersion=id%3A5866\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":{\"drupal_internal__target_id\":91}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/field_resource_type?resourceVersion=id%3A5866\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/field_resource_type?resourceVersion=id%3A5866\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":{\"drupal_internal__target_id\":66}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/field_roles?resourceVersion=id%3A5866\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/field_roles?resourceVersion=id%3A5866\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":{\"drupal_internal__target_id\":16}},{\"type\":\"taxonomy_term--topics\",\"id\":\"0bc7c1d0-b569-4514-b66c-367457dead7e\",\"meta\":{\"drupal_internal__target_id\":11}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/field_topics?resourceVersion=id%3A5866\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/cba2b00b-3f53-42bd-8a60-f175e1d47a0a/relationships/field_topics?resourceVersion=id%3A5866\"}}}}},{\"type\":\"node--library\",\"id\":\"596fc706-aa93-4b33-84a6-e648cf6c563d\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d?resourceVersion=id%3A5777\"}},\"attributes\":{\"drupal_internal__nid\":1141,\"drupal_internal__vid\":5777,\"langcode\":\"en\",\"revision_timestamp\":\"2024-08-05T16:04:17+00:00\",\"status\":true,\"title\":\"CMS Key Management Handbook \",\"created\":\"2023-08-23T13:26:44+00:00\",\"changed\":\"2024-08-05T16:04:17+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/policy-guidance/cms-key-management-handbook\",\"pid\":993,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":{\"value\":\"$24\",\"format\":\"body_text\",\"processed\":\"$25\",\"summary\":\"\"},\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_last_reviewed\":\"2022-10-14\",\"field_related_resources\":[{\"uri\":\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\",\"title\":\"NIST SP 800-57 Part 1 Rev. 5: Recommendations for Key Management\",\"options\":[],\"url\":\"https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final\"},{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security and Privacy Policy (IS2P2)\",\"options\":[],\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"},{\"uri\":\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/Policies\",\"title\":\"CMS Chief Information Officer (CIO) Policies \",\"options\":[],\"url\":\"https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/CIO-Directives-and-Policies/Policies\"}],\"field_short_description\":{\"value\":\"Guidance on the management lifecycle of cryptographic keys: data used to lock or unlock functions, including authentication, authorization, and encryption \",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eGuidance on the management lifecycle of cryptographic keys: data used to lock or unlock functions, including authentication, authorization, and encryption\u003c/p\u003e\\n\"}},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":{\"drupal_internal__target_id\":\"library\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/node_type?resourceVersion=id%3A5777\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/node_type?resourceVersion=id%3A5777\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"4420e728-6dc2-4022-bf8d-5bd1329e5e64\",\"meta\":{\"drupal_internal__target_id\":159}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/revision_uid?resourceVersion=id%3A5777\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/revision_uid?resourceVersion=id%3A5777\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":{\"drupal_internal__target_id\":26}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/uid?resourceVersion=id%3A5777\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/uid?resourceVersion=id%3A5777\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":{\"drupal_internal__target_id\":91}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/field_resource_type?resourceVersion=id%3A5777\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/field_resource_type?resourceVersion=id%3A5777\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":{\"drupal_internal__target_id\":66}},{\"type\":\"taxonomy_term--roles\",\"id\":\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\",\"meta\":{\"drupal_internal__target_id\":81}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}},{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"meta\":{\"drupal_internal__target_id\":71}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/field_roles?resourceVersion=id%3A5777\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/field_roles?resourceVersion=id%3A5777\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":{\"drupal_internal__target_id\":16}},{\"type\":\"taxonomy_term--topics\",\"id\":\"65ef6410-4066-4db4-be03-c8eb26b63305\",\"meta\":{\"drupal_internal__target_id\":36}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/field_topics?resourceVersion=id%3A5777\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/596fc706-aa93-4b33-84a6-e648cf6c563d/relationships/field_topics?resourceVersion=id%3A5777\"}}}}},{\"type\":\"node--library\",\"id\":\"fa2107f3-5c24-458b-b589-6c85321f2015\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015?resourceVersion=id%3A5712\"}},\"attributes\":{\"drupal_internal__nid\":366,\"drupal_internal__vid\":5712,\"langcode\":\"en\",\"revision_timestamp\":\"2024-07-25T14:57:26+00:00\",\"status\":true,\"title\":\"CMS Information System Security Officer (ISSO) Handbook\",\"created\":\"2022-08-29T16:40:17+00:00\",\"changed\":\"2024-07-25T14:57:26+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook\",\"pid\":356,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":{\"value\":\"$26\",\"format\":\"body_text\",\"processed\":\"$27\",\"summary\":\"\"},\"field_contact_email\":\"ISSO@cms.hhs.gov\",\"field_contact_name\":\"ISSO Support Team\",\"field_last_reviewed\":\"2024-07-15\",\"field_related_resources\":[{\"uri\":\"entity:node/376\",\"title\":\"Information System Security Officer (ISSO)\",\"options\":[],\"url\":\"/ispg/information-system-security-officer-isso\"},{\"uri\":\"entity:node/721\",\"title\":\"ISSO Appointment Letter\",\"options\":[],\"url\":\"/learn/isso-appointment-letter\"},{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security and Privacy Policy (IS2P2)\",\"options\":[],\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"}],\"field_short_description\":{\"value\":\"Guidance to help ISSOs in their daily work, including role descriptions, resources, points of contact, and training\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eGuidance to help ISSOs in their daily work, including role descriptions, resources, points of contact, and training\u003c/p\u003e\\n\"}},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":{\"drupal_internal__target_id\":\"library\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/node_type?resourceVersion=id%3A5712\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/node_type?resourceVersion=id%3A5712\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":{\"drupal_internal__target_id\":6}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/revision_uid?resourceVersion=id%3A5712\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/revision_uid?resourceVersion=id%3A5712\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":{\"drupal_internal__target_id\":26}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/uid?resourceVersion=id%3A5712\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/uid?resourceVersion=id%3A5712\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":{\"drupal_internal__target_id\":91}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/field_resource_type?resourceVersion=id%3A5712\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/field_resource_type?resourceVersion=id%3A5712\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/field_roles?resourceVersion=id%3A5712\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/field_roles?resourceVersion=id%3A5712\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"8b8ffea0-3b0b-404d-8442-7f3a4602482d\",\"meta\":{\"drupal_internal__target_id\":56}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/field_topics?resourceVersion=id%3A5712\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/fa2107f3-5c24-458b-b589-6c85321f2015/relationships/field_topics?resourceVersion=id%3A5712\"}}}}}],\"includedMap\":{\"d185e460-4998-4d2b-85cb-b04f304dfb1b\":\"$28\",\"e352e203-fe9c-47ba-af75-2c7f8302fca8\":\"$32\",\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\":\"$36\",\"9d999ae3-b43c-45fb-973e-dffe50c27da5\":\"$50\",\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\":\"$6a\",\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\":\"$84\",\"f591f442-c0b0-4b8e-af66-7998a3329f34\":\"$9e\",\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\":\"$b8\",\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\":\"$d2\",\"6348291e-48d1-4a0e-9a57-ac86d40af43e\":\"$ec\",\"f5048b9a-b22a-4e67-abde-e964ff928b22\":\"$101\",\"8b6ef8b3-acd0-47f9-8050-9c68b8c24ada\":\"$114\",\"0f74c41a-2461-4cf5-b11e-ff7ce0b96f66\":\"$123\",\"fe6656d7-9b88-4a4c-a27f-e41c610ab068\":\"$135\",\"80d4e83c-5a1f-466b-9518-5400af425d7f\":\"$147\",\"9967f006-5e08-4568-b636-63e8e8050a8f\":\"$159\",\"e0709a54-90c1-4f0d-b02a-5e8dce6acc17\":\"$16b\",\"9c79715c-bf72-4433-9d27-f6a64a297c18\":\"$17d\",\"4c71fa83-e15c-4187-a479-696657ea5e15\":\"$18f\",\"ddb65a30-0e50-44c7-a6bd-084b9a7e6f06\":\"$1ce\",\"4d1cc2c6-4cc0-4999-b30f-8dc07a2a6a3e\":\"$20b\",\"cba2b00b-3f53-42bd-8a60-f175e1d47a0a\":\"$244\",\"596fc706-aa93-4b33-84a6-e648cf6c563d\":\"$281\",\"fa2107f3-5c24-458b-b589-6c85321f2015\":\"$2c2\"}}}]\n"])</script><script>self.__next_f.push([1,"a:[[\"$\",\"meta\",\"0\",{\"name\":\"viewport\",\"content\":\"width=device-width, initial-scale=1\"}],[\"$\",\"meta\",\"1\",{\"charSet\":\"utf-8\"}],[\"$\",\"title\",\"2\",{\"children\":\"CMS Security and Privacy Handbooks | CMS Information Security \u0026 Privacy Group\"}],[\"$\",\"meta\",\"3\",{\"name\":\"description\",\"content\":\"Procedures to help CMS staff and contractors implement federal policies and standards for information security and privacy\"}],[\"$\",\"link\",\"4\",{\"rel\":\"canonical\",\"href\":\"https://security.cms.gov/learn/cms-security-and-privacy-handbooks\"}],[\"$\",\"meta\",\"5\",{\"name\":\"google-site-verification\",\"content\":\"GMZIwBDJgz_o_JYUB2GpJazkrs7P85BaWDsoCjxF32M\"}],[\"$\",\"meta\",\"6\",{\"property\":\"og:title\",\"content\":\"CMS Security and Privacy Handbooks | CMS Information Security \u0026 Privacy Group\"}],[\"$\",\"meta\",\"7\",{\"property\":\"og:description\",\"content\":\"Procedures to help CMS staff and contractors implement federal policies and standards for information security and privacy\"}],[\"$\",\"meta\",\"8\",{\"property\":\"og:url\",\"content\":\"https://security.cms.gov/learn/cms-security-and-privacy-handbooks\"}],[\"$\",\"meta\",\"9\",{\"property\":\"og:image:type\",\"content\":\"image/jpeg\"}],[\"$\",\"meta\",\"10\",{\"property\":\"og:image:width\",\"content\":\"1200\"}],[\"$\",\"meta\",\"11\",{\"property\":\"og:image:height\",\"content\":\"630\"}],[\"$\",\"meta\",\"12\",{\"property\":\"og:image\",\"content\":\"https://security.cms.gov/learn/cms-security-and-privacy-handbooks/opengraph-image.jpg?d21225707c5ed280\"}],[\"$\",\"meta\",\"13\",{\"property\":\"og:type\",\"content\":\"website\"}],[\"$\",\"meta\",\"14\",{\"name\":\"twitter:card\",\"content\":\"summary_large_image\"}],[\"$\",\"meta\",\"15\",{\"name\":\"twitter:title\",\"content\":\"CMS Security and Privacy Handbooks | CMS Information Security \u0026 Privacy Group\"}],[\"$\",\"meta\",\"16\",{\"name\":\"twitter:description\",\"content\":\"Procedures to help CMS staff and contractors implement federal policies and standards for information security and privacy\"}],[\"$\",\"meta\",\"17\",{\"name\":\"twitter:image:type\",\"content\":\"image/jpeg\"}],[\"$\",\"meta\",\"18\",{\"name\":\"twitter:image:width\",\"content\":\"1200\"}],[\"$\",\"meta\",\"19\",{\"name\":\"twitter:image:height\",\"content\":\"630\"}],[\"$\",\"meta\",\"20\",{\"name\":\"twitter:image\",\"content\":\"https://security.cms.gov/learn/cms-security-and-privacy-handbooks/opengraph-image.jpg?d21225707c5ed280\"}],[\"$\",\"link\",\"21\",{\"rel\":\"icon\",\"href\":\"/favicon.ico\",\"type\":\"image/x-icon\",\"sizes\":\"48x48\"}]]\n"])</script><script>self.__next_f.push([1,"4:null\n"])</script></body></html> |