US · guidance
CMS Pub. 100-17, ch. 117_systems_security, § 3.1
System Security and Privacy Plan (SSPP)
(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
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.