CLOUD INFRASTRUCTURE
The starting position
The customer was a commercial SaaS provider with an established civilian agency pipeline and no federal authorization. Their product was mature, their commercial security posture was genuinely good, and their leadership had been told by three separate consultancies that FedRAMP High would take between two and three years.
That estimate was not wrong for the path they were being sold, which was to build and accredit their own boundary. Standing up a compliant infrastructure layer, evidencing it against the full control catalogue, and carrying it through assessment is a multi-year program for a team that has never done it.
What inheritance changed
Deploying inside an already-authorized boundary changes the arithmetic before any work starts. Controls that are wholly satisfied by the infrastructure provider leave the customer's scope entirely. Controls that are shared are documented once by the provider, with the customer describing only their portion. What remains is the application layer, which is the part the customer actually knows how to talk about.
For this engagement the split landed at roughly two thirds inherited or shared, one third customer responsibility. The remaining third was concentrated in areas the customer was already strong: access management inside their own application, secure development practice, incident response for their own service.
The first ninety days
Work began with a boundary workshop rather than an engineering sprint. The output was a diagram naming every data flow crossing the authorization boundary and, for each one, the party responsible for the controls protecting it. Nothing was deployed until that diagram was agreed, because a boundary drawn after the migration is a boundary drawn around whatever happened to be built.
Migration itself took under six weeks. The application moved into dedicated enclaves with no architectural rewrite, because the isolation properties it needed were provided by the platform rather than the code.
Where the time actually went
The schedule risk was not technical. It was documentation throughput.
A System Security Plan at the High baseline runs to several hundred pages of control narrative, and every statement in it has to be defensible against evidence. The customer's engineers could describe their controls accurately in conversation and could not write them in the form an assessor expects. That gap, not any engineering problem, is what consumes months on most authorization efforts.
The mitigation was to write against the inherited narrative rather than from scratch. Provider control descriptions were supplied in the format the package required, so the customer's authors edited and extended rather than composing. Review cycles ran weekly against a fixed control family sequence instead of accumulating into a single pre-assessment scramble.
Sponsorship
The largest single determinant of the timeline was agency sponsorship, secured in month two. Sponsorship sets the assessment calendar, and an authorization effort without it can complete every technical milestone and still wait indefinitely for a decision.
Teams routinely treat sponsorship as a downstream step to be handled once the package is ready. Reversing that order is the highest-leverage scheduling decision available on any federal authorization.
Outcome
The customer reached an authorization decision eleven months after kickoff, against consultancy estimates of twenty-four to thirty-six. The distribution of effort is the part worth carrying away:
- Six weeks of migration engineering.
- Roughly seven months of documentation, review, and evidence collection.
- The remainder in assessment and decision.
Inheritance did not remove the work. It removed the work the customer had no reason to be doing, and left them with the part only they could do.