Control Origination Demystified

Control Origination can be confusing. Get it wrong and your System Security Plan (SSP) control definitions will not be certifiable. This series of illustrations an explanation to guide you through Control Origination requirements present in all NIST and FISMA assessments such as FedRAMP, CMMC, 800-53, HIPAA, CJIS, DFARS, 800-171 and others.

All controls originate from a system or from a business process. It is important to describe where the control originates from so that it is clear whose responsibility it is to implement, manage and monitor the control. In some cases, the responsibility is shared by a CSP and by the customer. Use the definitions in the illustrations below to indicate where each security control originates from.

Throughout the SSP, policies and procedures must be explicitly referenced (title and date or version) so that it is clear which document is being referred to. Section numbers or similar mechanisms should allow the reviewer to easily find the reference.

For SaaS and PaaS systems that are inheriting controls from an IaaS (or anything lower in the stack), the “inherited” option in the SSP must be selected, and the implementation description must simply say “inherited.” Authorized reviewers will determine whether the control-set is appropriate or not.

The NIST term "organization defined" must be interpreted as being the CSP's responsibility, unless otherwise indicated. In some cases the JAB has chosen to define or provide, in others they have left the decision up to the CSP.

The official Control Origination classifications are:

• Service Provider Corporate
• Service Provider System Specific
• Service Provider Hybrid (Corporate and System Specific)
• Configured by Customer (Customer System Specific)
• Provided by Customer (Customer System Specific)
• Shared (Service Provider and Customer Responsibility)
• Inherited from pre-existing FedRAMP Authorization