CMS ARC-AMPE SSPP Ownership Levels for Inherited Controls

Ownership Structure Overview

Two-level Ownership Example

In a two-tier structure:

• Owner 1 (System/Application Level):
  The primary system or application operating within the authorization boundary.

• Owner 2 (Inherited Control Provider):
  The entity, such as a cloud service provider or physical data center, that implements controls the system inherits.

  

Three-level Ownership Example

A three-level structure is used when multiple external layers contribute to inherited security functions. Common ownership tiers include:

1.  System/Application (Boundary)
   • The primary system or application operates within the authorization boundary.
2. Enterprise Level Controls
   • The main system under which the application operates as a subsidiary
3. State, Cloud, or Physical Infrastructure Providers

   • The entity, such as a cloud service provider or physical data center  that implements the controls the system inherits.

     

Master/Overall Control Status:

The SSPP requires a consolidated status reflecting the responsibilities of both owners:

• If the system exclusively inherits a control, the status is Inherited.
• If the system both inherits controls and implements its own components of a control, the status is Implemented.

Additional Guidance

• Enterprise-level services, such as centralized logging, monitoring, or security operations, should be documented when they provide inherited controls from outside the system boundary.
  • Control implementation is provided by outside sources other than the system (i.e., GSS, physical security, SOC/NOC, etc.).
• Consistent application of ownership levels and inheritance or implementation statuses is essential to maintain clarity and prevent misinterpretation across controls.
• Although Owner 1 must consistently represent the system boundary, the SSPP does not mandate a specific order for subsequent owners. Nonetheless, maintaining consistent ordering across all controls improves clarity and supports an efficient audit process.

Implementation Steps

1. Identify All Parties Involved in Control Implementation:  Determine all systems, enterprise, cloud, and external contributors involved in fulfilling control requirements.
2. Establish the System Boundary (Owner 1):  Confirm the application or system within the authorization boundary. This entity must always serve as Owner 1.
3. Determine Inherited Control Providers:  Identify any parties that provide controls the system inherits and assign them sequentially as Owner 2, Owner 3, etc.
4. Document Ownership in a Consistent Order:  Maintain the same ownership sequence across all controls to ensure clarity and auditability.
5. Assign the Appropriate Control Status:  Evaluate each control to determine whether it is implemented, inherited, or jointly supported, and apply the correct overall status.
6. Review for Completeness and Consistency:  Verify that all ownership layers are present, statuses are correct, and terminology is uniform throughout the SSPP.

Conclusion

The enhanced SSPP ownership model establishes a clearer and more structured method for documenting control responsibilities. By accurately identifying how controls are implemented and inherited across all applicable layers, organizations can present a more precise security posture and streamline the audit process. Organizations may assign certain implementation responsibilities to downstream entities, but doing so does not eliminate or ‘write off’ their security obligations. Even when another party performs the control activity, organizations retain accountability for ensuring the requirement is correctly implemented, monitored, and effective. Consistent, thorough, and well-structured documentation ensures alignment with CMS expectations and supports a more effective and transparent assessment.

References: 

CMS AE ARC-AMPE SSPP

CMS EDE/DEE ARC-AMPE SSPP