The CMS Security Implementation Checklist for planning, testing, and rollback covers document controls, analyze change impact, and prove recovery. CMS here means Centers for Medicare & Medicaid Services, not a website content management system. System owners use it before changes, during testing, and before go-live. It links planning documents to exercises, fixes, and restore checks.
Official resources:
- Read the official guidance from CMS — Use this primary source to verify the official guidance.
- Read the official guidance from CMS — Use this primary source to verify the official guidance.
Table of Contents
- What belongs in the security plan?
- What must you check before a change?
- How do you test recovery?
- How do you prove rollback works?
What belongs in the security plan?
Centers for Medicare & Medicaid Services requires owners to list only controls actually in place in the System Security and Privacy Plan. That plan acts as the primary reference for CMS, GAO, or other testing and evaluation, as described in the CMS guidance portal.
For a site release, record the exact version, setting, and access control you deployed. Leave planned or disabled controls out until they are live.
What must you check before a change?
CMS requires a Security Impact Analysis before a system change. The review forces updates to the security plan, risk assessment, contingency plan, and privacy assessment. It also forces a decision on third-party security testing, as CMS explains in its impact-analysis guidance.
For a web project, treat plugin updates, auth changes, and hosting moves as system changes. Pause and update these items first: Assign one owner to approve the analysis. Do not deploy until documents and test decision match the build.
- what changed and why
- which documents need revision
- whether outside testing is needed
How do you test recovery?
CMS requires each Information System Contingency Plan to be exercised at least once every 365 days. The exercise is often a tabletop walkthrough so recovery staff know their roles, according to CMS contingency-plan guidance. CMS owners must also schedule yearly testing, training, and exercises and finish corrective-action plans for flaws found in testing, per the CMS exercise handbook.
NIST describes the same loop in SP 800-34: develop the plan, test and train, then use results to update the plan. Run a drill with developers, support, and communications in one room. Give each person a task, such as restoring staging, checking logins, or posting status.
How do you prove rollback works?
CMS requires penetration testing of High Value Asset systems every 365 days or after a major change, with scope recorded in the security plan. CISA, MS-ISAC, NSA, and FBI guidance advises offline, encrypted backups, regular restore tests in a disaster-recovery scenario, and current golden images, as detailed in the StopRansomware Guide. CISA notes that contingency help arrives as a custom plan, exercise, and after-action report.
An untested backup is not proof, so stage the restore, test it, and fix gaps before go-live. Keep one tested restore path for content, users, and keys. Block release when the restore test fails.
