Why are there "differences" between the CIS/CRM and Appendix A?

System generated deliverables using Risk Solutions enables a user to report more granular details in the CIS/CRM than in the SSP Appendix A.

Overview

It is natural to assume that two documents intended to portray similar information should match field for field. In theory the CIS/CRM and SSP Appendix A templates do match. However, there is a key difference in the template designs that can lead to "differences".

At what level are control implementation status and origination documented in the respective documents?

• SSP Appendix A: Control level
• CIS/CRM: Control part or enhancement level

At what level does Paramify enable you to manage implementation status?

• Risk Solution (security capability) level

At what level does Paramify enable you to manage origination and responsible role?

• Function level within a Risk Solution

In Paramify, Risk Solutions represent how security capabilities are deployed in a boundary with the respective responsible roles, origination, and implementation status. With one to many Risk Solutions mapped to control requirements at the control enhancement or part level for maximum accuracy, Paramify generates SSP Appendix A and CIS/CRM deliverables that are more precisely accurate than is feasible with the traditional manual updating of the FedRAMP templates while still generating the outputs at the levels designed in the FedRAMP templates, i.e. control level vs control part or enhancement level.

It is also worth noting that OSCAL does not include Shared or Hybrid as valid origination values. Therefore, Paramify aligns with OSCAL by indicating on the deliverables which customer and service provider originations derive a Shared or Hybrid origination. Selecting 3 check boxes is bringing clarity, not inaccuracy to the origination sections of these documents.

Example

Once the levels at which the details are captured on a Risk Solution and that multiple Risk Solutions can be used to response to a control requirement, the differences seen between the CIS/CRM and SSP Appendix A are understood to be consistent with the implementation details supporting the level of detail expected in the respective template. 

Let's look at AC-2 as an example showing the logical differences between the CIS and SSP Appendix A:

CIS

Implementation status is consistent in this example across all AC-2 control parts. It could have varied like is observed for Origination.

Origination is:

• the same (Shared & Inherited) across AC-2(a), AC-2(b), AC-2(d), AC-2(e), AC-2(f), AC-2(g), AC-2(i), AC-2(j), AC-2(k) while
• different for AC-2(c) which is Service Provider System Specific and Inherited and AC-2 (h) and AC-2(l) which are Service Provider System Specific only.

SSP Appendix A

In SSP Appendix A we see the information from the CIS is consolidated to the control level rather than the control part level.

Only one implementation status is checked because the implementation status is consistent across all control parts as observed in the CIS.

Originations of Service Provider (System Specific), Shared, and Inherited are checked to represent the control level origination across all control parts.

Paramify enables that if one control part is customer managed and another control part is service provider managed, the originations will be unique at the control part level in the CIS and Shared at the control level on the SSP Appendix A.

Conclusion

The system generated deliverables using Risk Solutions enables a user to report more granular details in the CIS/CRM than are represented in the SSP Appendix A. The differences are consistent with the template design accommodating greater specificity on the CIS/CRM than on the SSP Appendix A. The selections also align with OSCAL design. The differences observed are not issues but examples of the clarity provided by Paramify generated deliverables.