Almost everything written about RMF focuses on getting the first ATO. Far less gets written about what happens three years later, when that ATO is approaching its expiration date and the whole process starts again, except this time the system has been running in production, has accumulated changes, and the team that built the original package may have moved on entirely.
Reauthorization is a recurring fact of life for any ISSO who stays with a system long enough, and it’s different from a first-time ATO in ways that matter. This guide covers what triggers it, what carries over, what gets re-examined, and how continuous monitoring quality determines whether the whole thing is smooth or painful.
What Triggers Reauthorization
The most predictable trigger is the ATO’s expiration date itself, typically set at issuance and often around three years out, though this varies by organization and risk posture. Less predictable triggers include significant changes to the system that exceed what routine configuration management and security impact analysis can absorb, a major security incident that calls the existing risk acceptance into question, or a shift in the system’s categorization if its data types or mission have changed.
The expiration date is the one that catches people off guard most often, not because it’s a surprise on the calendar, but because three years is long enough for institutional memory to fade. The person who built the original package may have moved to a different role or a different company. The documentation exists, but the context behind certain decisions doesn’t always travel with it.
Real-World Example: The Six-Month Wake-Up Call
A system’s ATO was set to expire in six months, and the realization landed during what was supposed to be a routine continuous monitoring review. The SSP hadn’t been substantively updated since the original authorization. In the time since, the system had gone through two infrastructure changes, added a new data feed, and the team had quietly stopped using one of the tools that an earlier control implementation statement specifically named.
None of these changes had been individually catastrophic, and each had gone through some form of change approval at the time. But nobody had gone back to the SSP to update the narratives, which meant the document no longer described the system as it actually existed. Six months sounds like a lot of time, until you realize that updating dozens of control narratives, regenerating diagrams, and re-validating evidence is itself a multi-week effort, even before the formal assessment starts.
The gap between what your SSP says and what your system actually does grows quietly. Reauthorization is when that gap gets measured all at once.
What Carries Over and What Gets Re-Examined
Reauthorization isn’t starting from zero, but it also isn’t a rubber stamp. Controls that haven’t changed and have solid continuous monitoring evidence behind them are usually the easiest part: the documentation exists, the evidence has been maintained, and the assessor can verify quickly.
What gets the most scrutiny is exactly what changed since the last authorization, and how well those changes were managed at the time. A system that went through several changes, each with a documented security impact analysis and an updated SSP section, demonstrates a working change management process. A system where changes happened but the documentation didn’t follow tells the assessor that the change management process itself may not be reliable, which raises questions well beyond the specific changes in question.
The POA&M also gets a hard look. An assessor reviewing a reauthorization package will compare the current POA&M against the one from the original authorization and the ones from interim continuous monitoring reviews. Findings that have lingered across multiple cycles without meaningful progress are a much bigger red flag at reauthorization than they might have been as standalone items, because they represent a pattern over time, not a single open item.
Real-World Example: The ISSO Who Made Reauthorization Boring
On a different system, the ISSO had treated continuous monitoring as an ongoing documentation practice rather than a periodic scramble. Every change went through the CCB with an updated SSP section attached before it was approved. Every POA&M review resulted in either closure with evidence or an honestly updated milestone, not a date pushed back without explanation.
When reauthorization came around, the bulk of the work was compiling and packaging what already existed rather than reconstructing it. The assessment itself went quickly, because the assessor could trace every change back to a documented decision and every open finding back to a real, current plan. Reauthorization wasn’t a project. It was closer to an audit of work that had already been done continuously.
Ongoing Authorization as an Alternative Model
Some organizations are moving toward Ongoing Authorization (often discussed alongside cATO, continuous ATO), where instead of a fixed expiration date and a periodic full reassessment, the system’s authorization is maintained continuously based on real-time or near-real-time monitoring data, with the AO retaining visibility into the system’s risk posture on an ongoing basis rather than at fixed three-year intervals.
This doesn’t eliminate the work. If anything, it requires the kind of continuous documentation discipline described above as a baseline requirement rather than a best practice, since the entire model depends on monitoring data being current and trustworthy at all times, not just freshened up before a deadline. For systems that qualify, it can reduce the disruptive nature of periodic reauthorization, but it raises the bar for how rigorous day-to-day continuous monitoring needs to be.
A Practical Approach to Reauthorization
Start tracking your expiration date well before it becomes urgent, and treat the months leading up to it as a scheduled review, not a response to a deadline. A quarterly check of how current the SSP is relative to the actual system catches drift early, when it’s a small correction, instead of late, when it’s a backlog.
When a change happens, update the relevant SSP section as part of closing out that change, not as a separate task to revisit later. The closer documentation updates sit to the actual change, the less likely they are to get lost.
And treat your POA&M reviews as genuinely consequential, not procedural. A POA&M that accurately reflects reality at every review is the single biggest factor in whether reauthorization feels like packaging existing work or starting a new project from a standing start.
Final Thoughts
Reauthorization rewards exactly the habits that make continuous monitoring meaningful in the first place: documentation that stays current, changes that get recorded as they happen, and a POA&M that reflects real status rather than aspirational dates. None of that is reauthorization-specific advice. It’s the same discipline that makes every other part of RMF easier, and reauthorization is simply where the cost of skipping it shows up all at once.
If there’s one thread running through this whole series, from writing the SSP to managing the POA&M to navigating eMASS to facing reauthorization, it’s that RMF rewards accuracy over effort. A package that honestly and currently reflects the system, even with open findings, moves faster and generates fewer surprises than one that looks complete but doesn’t match reality. That’s true on day one of an authorization, and it’s still true on the day it comes up for renewal.
Leave a Reply