Bindinglaw

US · guidance

CMS Pub. 100-17, ch. 117_systems_security, § 3.1

System Security and Privacy Plan (SSPP)

activein force · 2026-08-25 – presentas-observed

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

Key Requirements

Business partners are required to update and re-certify the SSPP every 365 days unless

there are changes that would necessitate a more frequent update. Updates to the SSPP

shall be performed via CFACTS.

Defining a system boundary is a key step that must be completed before an SSPP can be

accurately documented.

The SSPP should address how the control environment is implemented to mitigate risks

identified in the information security risk assessment.

The objective of an information security program is to maintain and improve the protection of

sensitive/critical IT resources. All business partner systems used to process, transmit, or store

Medicare-related data have some level of sensitivity and require protection. The protection of a

system shall be documented in an SSPP. The completion of an SSPP is a requirement of the

Federal Information Security Management Act of 2014 (FISMA), Privacy Act of 1974, As

Amended, Office of Management and Budget (OMB) Circular A-130, Management of Federal

Information Resources, Appendix III, Security of Federal Automated Information Resources, and

Public Law 100-235, the Computer Security Act of 1987. All Medicare claims-related applications

and systems categorized as either an MA or GSS shall be covered by SSPPs.

The purpose of an SSPP is to provide an overview of the security and privacy requirements of a

system and describe the controls that are implemented to meet those requirements. The SSPP also

delineates responsibilities and expected behavior of all individuals who access the system. The

SSPP should be viewed as documentation of the structured process of planning adequate and cost-effective security protection for a system. It should reflect input from various managers with

responsibilities concerning the system, including Business Owners, information owners, the system

operator, and the system security manager (i.e., SSO).

All business partners are required to maintain current security and privacy plans for their Medicare

claims-related GSSs and MAs in both the CFACTS and their System Security Profiles. The SSPP

documents the current level of security within the system or application; that is, actual implemented

controls, not planned controls. In addition, the SSPP serves as the primary documentation reference

for testing and evaluation, whether by CMS, the General Accounting Office (GAO), or other

oversight bodies. The SSPP is a sensitive document, as it may discuss uncorrected vulnerabilities

and may mention risks that have been accepted. Therefore, security and privacy plans should be

distributed only on a need-to-know basis.

The SSPP shall be recertified by business partner management and the signed copy made available

to the SSO and authorized external auditors as required. The SSO and business partner are

responsible for reviewing the SSPP on an annual basis to ensure that it is up to date. The objective

of these annual reviews is to verify that the controls selected or installed remain adequate to provide

a level of protection to reach an acceptable level of risk to operate the system.

All business partner Medicare claims-related SSPPs shall be developed and documented in

accordance with the latest instruction from CMS.

SSPP shall be recertified within 365 days from the previous certification date. The SSPP shall also

be reviewed prior to recertification (within the original certification timeframe) to determine

whether an update is required. The SSPP shall be updated if there has been a significant change or

the security posture has changed. Examples of significant change include but are not limited to:

transition from one standard system to another, replacement of major computer equipment, change

in operating system used, change in system boundaries, or any significant system modifications that

may impact the system’s security posture. Documentation of the review or the updated SSPP, if

applicable, shall be documented in the CFACTS, and placed in the System Security Profile.

Contractors updating their current security and privacy plan(s) or developing new security and

privacy plan(s) shall take into account Medicare claims processing front-end, back-end, and/or

other claims processing related systems.

Front-end systems are those systems Medicare contractors develop and maintain for use in their

operations areas and data centers to enter claims and claims-related data into the standard/shared

claims processing system. These front-end systems include, but are not limited to: electronic data

interchange, imaging systems, optical character recognition, manual claims entry, claims control,

provider, beneficiary, other payer databases, and other pre-claims processing business functions.

Back-end systems are those systems that Medicare contractors develop and maintain for use in their

operations areas and data centers to output claims processing information (i.e., checks, Medicare

summary notices, letters, etc.). These back-end systems include, but are not limited to: print mail,

1099 forms, post-payment medical reviews, customer service, appeals, overpayment written/phone

inquiries and separate claims reconciliation systems.

Within 10 business days of updating, developing or recertifying an SSPP, CFACTS must be

updated.

History

(Rev. 15.1; Issued: 07-17-25; Effective: 02-28-25; Implementation: 08-18-25)

Provenance

Source
cms.gov
Retrieved
2026-08-25
Edition
iom-2026-08-25
Content hash
1333e45525a61597f065e47d5bd1e3faba99ac3f6a8324206c4121e1b8fce65f
View the official source →

The link goes to the issuing authority’s own document — the one we read to produce this record. Where a source publishes whole titles rather than sections, your browser may need a moment to jump to the provision.

Unofficial copy of government-published law, reproduced from official sources with full provenance. Not an official publication; verify against official sources before relying on it in a filing. Records in the 'guidance' corpus, and only that corpus, are sub-regulatory (interpretive guidelines, survey procedures) and are not binding law. Validity bounds follow each jurisdiction's declared temporalBasis.

Coverage · API docs

Bindinglaw

Point-in-time US law with the receipt attached. Source URL, retrieval time, content hash, and validity dates on every answer.

curl api.binding.law/v1/law/coverage

© 2026 binding.law · a Jubal, Inc. productAttorneys and firms never pay. Ever.