Changing incentives for Authorizing Officials alters the risk calculation

Federal agencies have to contend with a landscape that is constantly changing. When people come and go from security roles in an organization, the risk tolerance can change. Knowledge may be lost or there may not be sufficient documentation to understand why prior risk decisions were made. Time may simply have passed or the underlying reasoning may no longer apply.

This is especially true when Authorizing Officials change. The risk calculation of a previous Authorizing Official may not be in line with that of the new official. Not only is there irregularity and inconsistency in the way systems are authorized, there is irregularity in the way they are monitored, managed, and reauthorized over their lifespan.

“We started the project with maybe two to three months of high level air cover… and then as soon as the transition happened, [the Authorizing Official] was out. We had a new CIO who could not actively kill the project but was just not at all interested in lending their support.”

“We have our entire public cloud in FedRAMP Moderate…. We do have times where we have to go back to the Authorization Board or go back to the Authorizing Official and talk through why the previous staff agreed to this and fill them in in terms of what we’re doing. And every now and then a different interpretation results in changes that we have to implement to maintain compliance.”

This shift in incentives can also occur after systems are authorized for the first time. Before a system is authorized, the incentive structures encourage the maximum number of controls. They effectively discourage authorization. Waivers are difficult to get.

Once a system is authorized, and after it becomes part of the way the agency works, that dynamic shifts. It becomes difficult not to continue re-authorizing a system that is actively in use. Waivers become more frequent. Still, the incentives are not necessarily to modernize or improve the system. Too many changes would trigger a new ATO process. Therefore, when reviewing the security of an existing system, the incentive is to change as little as possible so the existing Authority to Operate remains valid.

“Same thing with a CIO where if they have an old system from a previous CIO that the previous CIO approved, they have the option of improving it and changing it up, and therefore their signature has to go on all the new documentation, or leaving it as it is. Then if it breaks, it’s not their fault, it’s the fault of the previous person that approved it.”

Developers and Program Officers must contend not only with the personalities and risk tolerance of one Authorizing Official. Over time, they are likely to encounter several officials with different opinions and comfort with risk. This is especially problematic for private sector vendors who sell off-the-shelf solutions to the government. The more variability they encounter, the less attractive the government is as a market.