FedRAMP is usually explained as a control list, and that explanation is why so many companies start it twice. The control list is the smallest part. What actually consumes the year is the engineering: drawing a boundary around a platform that was never designed to have one, separating a government tenant from a commercial one without forking the product, rebuilding identity and logging so an assessor can trace a single administrative action end to end, and producing a document set that describes the system as it truly runs rather than as the architecture diagram wishes it ran. A company that treats FedRAMP as a compliance project staffs it with compliance people and discovers in month seven that every open finding is an engineering change.
This is written for the person who has to own that program: a chief technology officer, head of platform, or head of security at a company with a working commercial data platform and a sales team hearing the word from federal buyers. The question is not whether FedRAMP is worth doing. It is what the plan looks like, in what order, and how to run it without stopping the roadmap for a year.
What authorization actually is
An authorization is a decision by a federal agency official to accept the risk of running your service with government data in it. Everything else in the program exists to give that official enough evidence to make the decision and enough ongoing evidence to keep it. That framing matters because it explains the shape of the work. You are not passing a test. You are building an evidence system that runs continuously, and the assessment is a sampling of it.
Three artifacts carry the weight. The system security plan describes the service, its boundary, its components, its data flows, and how each control is implemented in this specific system. A third-party assessment organization then tests a sample of those implementations and writes a security assessment report with findings. The plan of action and milestones tracks what is not yet fixed, with owners and dates. An agency reviews all three and issues the authorization. After that, monthly evidence keeps it alive.
The impact level determines the size of everything. A moderate baseline governs most systems holding data that is sensitive but not national-security-related, which is where nearly all commercial data platforms land. High applies where a loss would be severe. There is a low baseline and a tailored path for services with a very small footprint, which suits a narrow product but not an enterprise platform with an admin console, a query engine and an integration surface.
Where the engineering effort concentrates on a first authorization
Editorial weighting, illustrative rather than measured. The last row is deliberately low: the writing is the visible part and the smallest part.
The boundary is the first engineering decision and the most expensive to get wrong
The authorization boundary is the set of components inside the assessment. Everything inside it must meet the baseline. Everything outside it must either be an authorized service you inherit from, or a connection you document and defend. Companies draw this line badly in two opposite directions and pay for both.
Drawn too wide, the boundary swallows the corporate environment. Your identity provider, your ticketing system, your build pipeline, your observability stack, your customer support tooling and the laptops of everyone who can reach production all end up in scope, which means the entire company is now inside a federal control regime. Drawn too narrow, the boundary excludes something an assessor will insist belongs inside, usually the build pipeline or the support path, and the finding arrives after the assessment has started, when changing it costs a re-test.
The useful test is data and control. If a component stores, processes or transmits federal data, it is inside. If a component can change the state of a component that does, it is inside. That second half is what pulls in continuous integration systems, configuration management, secret stores and administrative jump paths. A build system that can push a container image into the production cluster controls production. An assessor will say so.
The corollary is that most enterprise data platforms need a genuinely separate deployment for government work: separate accounts or subscriptions, separate identity, separate secret material, separate logging destinations and a separate build target, all driven from the same source repository. Separate deployment, one codebase. Get that wrong in either direction and you either fork the product, which is a permanent tax, or you drag the commercial business into the boundary, which is a different permanent tax.
The architecture changes almost every platform needs
Below are the changes we see repeatedly when a commercial platform is measured against a moderate baseline. None of these is exotic. Together they are six to nine months of engineering if they are discovered one at a time and considerably less if they are planned as one piece of work.
Identity separated and hardened. Federal users and federal administrators authenticate through an identity path that is inside the boundary and enforces phishing-resistant multi-factor for privileged access. In practice this means the government deployment cannot lean on the same commercial single sign-on tenant your staff use for everything else, and service-to-service authentication has to move to short-lived credentials issued by something inside the boundary.
Privileged access reworked. Standing administrative access is the single most common finding. The target state is that nobody holds permanent production admin rights; access is requested, approved, time-boxed, logged, and expires. Building that well takes a real access broker, a break-glass path with its own alerting, and a review cadence that produces evidence.
Logging turned into an audit record. Application logs written for debugging are not an audit trail. The baseline expects a record of security-relevant events, protected from the people who could alter them, retained for a defined period with some of it kept online and searchable, time-synchronized against an authoritative source, and reviewable. Most platforms have to add an append-only destination outside the reach of platform administrators and add event types they never emitted, particularly around authorization decisions, data export and configuration change.
Cryptography and key custody. Data encrypted at rest and in transit is table stakes. What changes is the module and the custody: validated cryptographic modules, keys held in a hardware-backed service inside the boundary, rotation that is scheduled and evidenced, and a defensible answer to the question of who can decrypt customer data and under what approval.
Vulnerability management as a pipeline, not a scan. The program expects operating system, container, database and web application scanning on a monthly rhythm, with remediation timelines by severity and a documented deviation process for what cannot be fixed. If your base images are updated when someone remembers, this becomes an engineering project: image rebuild automation, a patch pipeline with a service-level target, and inventory that is generated rather than maintained by hand.
Configuration and inventory generated from the source of truth. Assessors ask for a component inventory and a hardened baseline configuration. A spreadsheet inventory will be wrong within a week of writing it. Infrastructure as code, with inventory generated from state and drift detection running continuously, turns a recurring documentation chore into a build artifact.
Backup, continuity and the tested restore. Not the policy. The restore, performed, timed and written down, at a stated recovery objective.
Accessibility, if the product has a user interface. Section 508 conformance is a separate obligation from security, and it is evaluated by buyers independently of authorization. A platform with a rich query builder or dashboard surface will have real work here. It is easier done alongside the security work than after it.
The two paths to an authorization, and how to choose
There is a route through a sponsoring agency and a route through the program's own review board. They differ in who reviews your package, how long the queue is, and what the result buys you. The choice is usually made for you by whether you have a named agency that wants your product, which is why the sales motion and the compliance program have to be run as one plan rather than two.
| Dimension | Agency-sponsored | Program review path | Inheriting from an authorized platform |
|---|---|---|---|
| What starts it | A named agency with a use case and a willing authorizing official | An application, prioritization, and a queue | A hosting decision made before any of this begins |
| What you must have first | A federal customer who wants the product enough to sponsor | A demonstrable government demand signal | An architecture that actually uses the inherited controls |
| Where the risk sits | Sponsor turnover and shifting agency priorities | Queue position and review cycles outside your control | Over-claiming inheritance and having it disallowed |
| Effect on reuse | Other agencies review and reuse the package | Broad reuse, marketed through the program | Reduces your control count, not your obligation |
| Typical failure | Sponsor found late, after engineering is already spent | Applying with a platform not yet architecturally ready | Claiming a control the provider does not actually perform |
Inheritance deserves a note because it is where the most avoidable rework happens. Building on an authorized infrastructure provider genuinely reduces your work at the physical, environmental, network and hypervisor layers. But every control is fully inherited, partly inherited with a customer-side obligation, or entirely yours. Mapping each control against the provider's customer responsibility matrix before you write a single narrative prevents the situation where a third of your descriptions say "inherited" and the assessor disagrees.
Sequencing that avoids rework
The order matters more than the pace. Almost every expensive FedRAMP program we have seen went wrong by running the documentation ahead of the engineering, producing a system security plan describing a system that did not exist yet, then rewriting it as the architecture caught up. Documentation should trail engineering by weeks, never lead it by months.
A sequence that keeps documentation behind the engineering
Two sequencing rules save the most money. First, stand up the government deployment early and empty, then build into it, because retrofitting a boundary onto a running system is where the schedule goes. Second, start the sponsor conversation at the beginning rather than when the package is nearly ready. A sponsor found in month two shapes the boundary and the priorities; a sponsor hunted in month ten is a stalled program with sunk engineering behind it.
Continuous monitoring is the part that outlives the project
The authorization is not the finish. What follows is a monthly obligation: scans submitted, the plan of action updated, deviations justified, significant changes notified and sometimes assessed before they ship, incidents reported within a defined window, and an annual assessment of a portion of the controls. This is a permanent operating function, not a project phase, and it is the part most companies fail to staff.
The engineering answer is automation. Scan collection and normalization, evidence packaging, inventory generation, drift alerts and the plan-of-action updates should be produced by pipeline rather than by a person with a calendar reminder. Built that way, monthly monitoring costs a fraction of a person. Built by hand, it costs one to two people permanently and degrades the moment they take a holiday.
The significant change process is the one that surprises product teams. A change that alters the boundary, adds a component, changes the cryptographic posture or introduces a new external connection may require notification and, in some cases, assessment before deployment. That is a constraint on the roadmap and it needs a defined internal path: a change triage that decides in days, not a committee that decides in weeks. Teams without that path either stop shipping to the government deployment or ship changes they should have declared.
What it costs, in the terms that matter
The cash cost of the independent assessment is real and quotable, and any assessor will quote it. The cost that decides whether the program succeeds is engineering capacity, and it is usually understated because the estimate is built from the control list rather than from the architecture changes.
The honest way to size it is to run a gap assessment first and convert each gap into an engineering estimate, in hours, by the team that would do the work. That produces a number your finance function can defend and your board can inspect. It also produces the more useful artifact: a ranked list of what to build, which is the actual program plan.
The opportunity cost is the one to argue about internally. If the platform team spends nine months on the authorization, the roadmap slips nine months, and the federal revenue that justified the program arrives against a product that has stopped moving. This is the specific reason to bring in outside engineering rather than to reassign the platform team. Not because the work is beyond them, but because doing it internally converts a revenue expansion into a roadmap freeze.
How we work inside your organization
We are an engineering firm. We build the changes, not just the documents, and we have built and deployed systems inside federal agencies under exactly these constraints, which is why the boundary conversation and the control narratives come from people who have had to defend both to an assessor.
In the first two weeks we deliver a gap assessment written as engineering work: each control that is not met, expressed as a specific change to a specific component, with an hours estimate and a dependency order. That document alone is usable whether or not you engage us further, and it is what your board or your audit committee should see before the program is funded.
In the following weeks we deliver a boundary diagram and a written boundary rationale, a customer responsibility matrix mapped against your hosting provider, a target architecture for identity, privileged access, logging and key management, and a schedule with the sponsor track running in parallel to the engineering track.
Then we build. Our engineers work inside your repositories, pipelines and review process, alongside your team: infrastructure code, identity integration, logging architecture, scanning and evidence automation, and the system security plan and policy set that describe them. We prepare your team for the assessment, sit with the assessor, and remediate findings.
What you keep. All of it. The code is yours, in your repositories, under your license, with a written present assignment of the intellectual property. The documentation is yours. The pipelines are yours. Your customer relationships are yours; we do not sell your product, and we do not hold your agency relationship. If you end the engagement, everything continues without us, and the handover is a rehearsal in which your team deploys while we watch, not a document we email.
How it is priced. In shape, two ways. Fixed-price milestones where the scope is definable, which suits the gap assessment, the boundary work, the document set and the assessment support. A committed team at a monthly rate where the work is a continuous build, which suits the identity, logging and automation construction. Most programs use both: fixed price at the front and the back, a committed team through the middle.
How it starts. One email with a one-page brief. Tell us what the platform is, where it runs, what the target impact level is, whether you have a sponsor in view, and the date that matters. We return a scoped, priced statement of work with the assumptions written down.
The failures worth naming
Compliance staffed without engineering. A program run by a governance team writes excellent documents describing a system that cannot pass. Every open finding is an engineering change, so engineering has to be in the room from week one with committed capacity, not consulted on request.
The boundary redrawn after the assessment starts. The most expensive single mistake, because it invalidates work already tested. Decide it, write the rationale, have it reviewed by someone who has defended one, and freeze it.
Inheritance over-claimed. Marking controls inherited without reading the provider's responsibility matrix produces a wave of findings at exactly the point in the schedule when there is no time to fix them.
A commercial fork created by accident. Once the government deployment diverges in code rather than in configuration, every future feature is built twice, and the second build is always late. Configuration difference is sustainable; code difference is not.
Continuous monitoring unstaffed. The authorization is achieved, the team returns to the roadmap, and monthly obligations slip. The recovery cost is far higher than the automation would have been.
The sponsor sought last. Engineering completed without a named agency is a package with no place to go. Run the sponsor track from the first month.
Signals that a platform is ready to start the program
Editorial weighting, illustrative rather than measured. The last row scores lower because it is the one item engineering cannot supply.
How to tell whether your platform is close
Six questions, answerable in an afternoon by your own engineers, that predict the size of the program better than any control checklist.
- Can you deploy the entire platform into a fresh, empty cloud account from source, with no manual steps? If yes, the boundary work is mostly configuration. If no, it is a build.
- Does anyone hold standing production administrative access? If yes, plan for an access broker, an approval path and a review cadence.
- Can you produce, for a chosen administrative action last month, a record of who did it, when, from where, and what it changed? If that takes more than a few minutes, the audit trail is engineering work.
- Is your component inventory generated from infrastructure state, or maintained by hand? Hand-maintained inventories fail the first sample.
- Do your base images rebuild and redeploy on a schedule without a human deciding to do it? This determines whether vulnerability remediation timelines are achievable.
- Has anyone actually restored the platform from backup and timed it? The policy is not the evidence.
Bottom line
FedRAMP is an engineering program with a documentation deliverable, not a documentation program with some engineering attached. The three decisions that determine its cost are made in the first eight weeks: where the boundary sits, whether the government deployment is a separate configuration of one codebase or a fork, and whether the sponsor track runs alongside the build or after it. Run the gap assessment as engineering estimates, build the identity, access, logging and automation layers before anyone writes a control narrative, and staff continuous monitoring as a permanent automated function rather than a person with a calendar. Companies that do it in that order authorize once. Companies that do not authorize twice, and pay for the roadmap they lost in between.
Frequently asked questions
Plan in stages rather than in a single number. A gap assessment takes weeks. The architecture changes most commercial platforms need, principally boundary separation, identity and privileged access, logging as an audit record, key management and scanning automation, take several months of real engineering. Documentation trails that work. The independent assessment and findings remediation take several more months, and the authorization decision follows. The variable that moves the total most is how much of the platform can already be deployed from source into an empty account, and whether a sponsoring agency is engaged early or late.
The boundary is the set of components inside the assessment, and everything inside it must meet the baseline. The working test is data and control: a component is inside if it stores, processes or transmits federal data, and also inside if it can change the state of a component that does. That second half pulls in build pipelines, configuration management, secret stores and administrative access paths, which is where most companies underdraw. Define it before any documentation is written and have the rationale reviewed by someone who has defended a boundary to an assessor.
No, and you should design specifically to avoid it. What you need is a separate deployment: separate accounts, separate identity, separate secrets, separate logging and a separate build target, all driven from the same source repository with differences expressed in configuration. Once the government edition diverges in code, every feature is built twice and the second build is always late. Configuration difference is sustainable indefinitely. Code difference becomes a permanent tax on the roadmap.
Partly. Building on an authorized infrastructure provider genuinely removes work at the physical, environmental, network and hypervisor layers. But every control is fully inherited, partly inherited with an obligation on your side, or entirely yours, and the provider publishes a customer responsibility matrix that says which. Map every control against that matrix before writing narratives. Over-claiming inheritance produces a wave of findings at the point in the schedule where there is no time left to engineer around them.
A standing monthly function: vulnerability scans across operating system, container, database and web application layers, an updated plan of action and milestones, justified deviations, notification and sometimes assessment of significant changes before they deploy, incident reporting within a defined window, and an annual assessment of a portion of the controls. Automate the collection, normalization and evidence packaging, and it costs a fraction of a person. Run it by hand and it costs one to two people permanently and degrades whenever they are away.