Changes to previous steps after Authorization is in Monitoring

[George P]

Hello,

I am investigating a customer request relating to how best to handle changes to a completely authorized package.  Forexample, if the Categorization needs to change, do I really need to go back one step at a time until I get back to Categorize?  Are there ramifications to coding a step change directly to Categorize?  How about adding/removing Controls based on changes to NIST requirements?

What have others done to support their customers after they completed the initial process?  We are striving for Continuous Authorization, but if we need to back out of everything to add Controls, that doesn't seem continuous.

I appreciate any ideas you can share.

[mattjohnston]

I too would appreciate any advice on this specific topic.  If an existing package is already in MONITOR and we need to edit applicable controls, should a new authorization package be created or should we walk the existing package all the way back to SELECT, and then process it normally back through all RMF workflow stages to re-authorize the system based on the new control set?

[Jing5]

Going back steps will change all existing controls to retired, that's definitely not continuous. I would suggest to create a new package to go through the re-authorization process, and leverage the build in capability to re-use the existing controls. When create a new package, that will offer the opportunity to continue with the current monitoring, while introducing additional controls till the new authorization completed. 

[George P]

If I am following correctly, you are suggesting that current active controls can be reassigned to a new Package?

[Jing5]

Leverage the standard script that populate the controls after completion of SELECT step to auto bring in those controls already in place, and create new items as needed. This script will not bring any controls that are in RETIRED state.