With the emergence of several IT risk management frameworks such as NIST CSF, RMF, SP 800-171, FedRAMP, and the more recent CMMC, many are asking if the general concept of reciprocity can be used to comply with several frameworks at once. For example, if an organization is already following the NIST SP 800-171, it should be a lot simpler to obtain a FedRAMP certification. Right?

The answer is yes, as long as your security program was developed to do so.  Unfortunately, if you implemented security with blinders on, simply to achieve a compliance credential, it will be much more difficult to leverage any of the effort completed in another framework. In either case, reciprocating control implementations and testing across frameworks requires careful consideration of scope, inheritance, and control mapping (just to name a few).

First and foremost, security that can be leveraged across frameworks largely depends on the scope of the framework. For example, if you implement a security control corporately, but it has no influence on your as-a-service offering, you are probably not going to be able to leverage that corporate control for FedRAMP.  Likewise, if you selected a specific identity and access management solution for your FedRAMP offering, but it is not cost-effective to deploy across your entire organization, you are not going to be able to leverage that compliance status for CMMC.

For security professionals that live in the daily minutiae of information security, this is not new. However, we need our business leaders to appreciate this reality in order to better understand why framework reciprocity is complicated.

Now let’s talk about control inheritance — a valuable tool in facilitating reciprocity among frameworks (if executed properly). Inheritance paints a more realistic picture of how security is implemented in an organization when it comes to layered security.  Creating these layers and assigning them to the appropriate business units increases accuracy and reduces the burden of validating controls for the inheriting components.  Inheritance spans across people, processes, and technology, and breaks down security controls into manageable pieces.  By implementing an inheritance framework of security controls, you are able to reduce the compliance footprint drastically.

What about control mapping? Several of the frameworks in question here provide documentation showing direct mapping to the control sets of other frameworks. Some may be tempted to believe that mapping two similar controls from different frameworks can satisfy the intent of both controls, but that’s simply not true. It can be seen as irresponsible to blankly claim reciprocity exists across more than one framework simply because similar controls have been mapped together. Compliance teams need to validate the specific security measure, not a generalized implementation of a security control. Performing the latter not only sets up businesses to fail, it undermines security teams that are tirelessly securing our technology and leading efforts to educate the masses to drive culture change.

All in all, most will agree there is no “easy” button, and coming to the realization that you actually need repeatable security across multiple frameworks is just the tip of the iceberg when it comes to reciprocity.  For instance, in addition to the topics addressed here, one also needs to take into account differences in data categorization and business impact.

If you’re ready to dive deeper into these topics, my colleague, Milica Green, and I will be hosting a webinar specifically addressing framework reciprocity on Thursday, July 30 at 2pm ET. I hope you will join us as we dissect the various intricacies of setting your organization up for reciprocity across multiple frameworks like NIST CSF, RMF, SP 800-171, FedRAMP, and CMMC.