The question is not whether you are compliant. It is where the data sits.
A commercial SaaS company usually meets its first federal opportunity through a customer, not a strategy. A program office finds the product, likes it, and asks a question that sounds administrative: are you FedRAMP? What the buyer means is more specific than the acronym. They are asking whether a federal authorizing official can sign a memo accepting the operational risk of putting government data into your system. Everything that follows is downstream of that one signature, and almost every expensive mistake in this transition comes from treating it as a paperwork problem instead of an architecture problem.
The architecture question is short: where does government data live, who can reach it, and can you prove both statements with evidence a third party generated. If your answer today is "in the same Postgres cluster as everyone else, reachable by any engineer with production access, and we can pull audit logs if you give us a week," you have identified the actual work. It is not a rewrite. It is usually a boundary, a set of controls that already half-exist, and eight to eighteen months of evidence production that nobody on your team has ever done before.
The good news rarely gets said plainly: the product itself is mostly fine. Federal buyers are not asking for different features. They want a different deployment posture, a different evidence trail, and a contract shape their contracting officer recognizes. Companies that understand this early spend on infrastructure and documentation. Companies that misunderstand it hire a federal sales team that cannot sell anything, because the thing they are selling cannot yet be bought.
Where the work actually lands, first federal deployment
Editorial weighting of where effort concentrates on a first federal deployment, read from published FedRAMP guidance and delivery experience. An ordering of effort, not a measured statistic.
FedRAMP is a program, not a certificate
FedRAMP was codified in statute by the FedRAMP Authorization Act, passed as part of the FY2023 National Defense Authorization Act, and it is administered by GSA. The operating principle is "authorize once, use many times." One agency sponsors an authorization, a third-party assessment organization tests the system against a control baseline drawn from NIST SP 800-53 Revision 5, the authorizing official issues an Authorization to Operate, and the package goes into the FedRAMP Marketplace where other agencies can issue their own ATOs by reviewing the existing package rather than starting over.
The baselines matter more than most first-time entrants expect. Low, Moderate and High correspond to FIPS 199 impact levels, and Moderate is where the overwhelming majority of federal SaaS lands. Moderate is roughly three hundred and twenty-five controls. High, which applies to systems where a compromise would have severe or catastrophic effect, is over four hundred. There is also FedRAMP Tailored Low-Impact SaaS for a narrow class of low-risk applications, which is real but rarely fits a product that touches actual agency records.
The number people quote for a Moderate authorization is four hundred thousand to two million dollars, and twelve to eighteen months. Both ranges are honest but measure different things. The low end assumes an engineering team that already runs infrastructure as code, centralized logging, and a mature change process. The high end is what it costs when a company has to build those practices during the assessment, which is the expensive order of operations. The assessment itself, the 3PAO engagement, is usually one hundred and fifty thousand to four hundred thousand of that total. The rest is your own engineering time and a continuous monitoring obligation that never ends.
FedRAMP 20x, the program's modernization effort, is worth watching rather than waiting for. It aims to replace narrative documents with machine-readable validation and shorten the path for cloud-native systems. The direction is real. Planning a 2026 entry around a process that has not stabilized is a way to lose a year.
The boundary is the single most consequential decision
An authorization boundary is the set of components inside the assessment: the systems that process, store or transmit federal data, plus the systems that provide security functions to them. Everything inside gets documented, tested and monitored. Everything outside does not. A commercial SaaS company drawing this line for the first time almost always draws it too wide, because the honest default is "our production environment," and production contains the entire company.
Drawing it deliberately returns more than any other engineering decision in the transition. The pattern that works is a separate deployment: a distinct cloud account or subscription, its own identity boundary, its own data stores, its own CI/CD path, its own logging. Government data never mixes with commercial tenants. Your corporate identity provider does not reach into it. Your standard developer laptop is not an administrative endpoint for it.
The alternative pattern, a logical boundary inside a shared multi-tenant environment, is possible and some large providers run it. For a company doing this the first time it is a bad trade. Logical separation means the shared components are in scope, which means your entire commercial platform is in scope, which means your commercial release cadence is now governed by federal change control. Companies discover this constraint about four months in, when a routine deploy turns into a significant change request.
Deployment topology and the regions that actually qualify
The three major cloud providers each operate a segregated region for this: AWS GovCloud (US), Azure Government, and Google Cloud Assured Workloads. They are not their commercial counterparts. GovCloud runs on separate infrastructure with US-person-only operational staffing and its own account structure, which means your existing accounts do not extend into it. Azure Government is a separate cloud with distinct endpoints. Assured Workloads applies policy constraints on top of commercial regions.
The consequence people underestimate is service parity. Not every managed service available commercially exists in GovCloud, and those that do frequently arrive twelve to twenty-four months later. If your product depends on a recent managed AI service, a serverless feature, or a marketplace offering, verify availability in the target region before promising a schedule. A one-afternoon audit saves a quarter.
For Department of Defense work the layer above FedRAMP is the DoD Cloud Computing Security Requirements Guide, which defines Impact Levels. IL2 covers public and low-confidentiality unclassified data. IL4 covers Controlled Unclassified Information and is where most defense SaaS lands. IL5 covers National Security System information and mission-critical CUI, and it requires dedicated infrastructure separation beyond what IL4 demands. Each step up narrows the set of qualifying regions and raises the cost.
| Buyer | What they will require | Realistic first-deal path |
|---|---|---|
| Civilian agency, low-sensitivity data | FedRAMP Low or Tailored, Section 508 conformance, standard commercial terms with FAR Part 12 | Agency-sponsored authorization, often through an existing reseller or a GSA Multiple Award Schedule listing |
| Civilian agency, program data or PII | FedRAMP Moderate, 800-53 Rev 5 Moderate baseline, privacy impact assessment support | Find an agency sponsor first. Without one there is no authorization path, only a JAB-successor queue |
| DoD program office, CUI | FedRAMP Moderate plus DoD SRG IL4, DFARS 252.204-7012, NIST SP 800-171 on your own systems | Frequently a subcontract to an integrator who already holds the customer relationship and the environment |
| DoD, mission systems | IL5, dedicated infrastructure, personnel screening, often facility requirements | Multi-year. Usually reached through a prime, an OTA consortium, or SBIR Phase III |
| State agency using federal funds | StateRAMP or a state equivalent, 2 CFR 200.303 safeguarding, sometimes IRS Publication 1075 or CJIS | Meaningfully faster and cheaper. A legitimate proving ground for the same controls |
The evidence problem is bigger than the control problem
Most commercial SaaS companies already satisfy a majority of the Moderate controls in substance. Encryption in transit and at rest, multi-factor authentication, vulnerability scanning, backup and recovery, incident response: these exist. What does not exist is the evidence that they exist, in the form and cadence an assessor accepts.
An assessor does not accept "we scan for vulnerabilities." They want the scan configuration, the output for the assessed period, the ticket showing each finding's remediation or accepted risk, the timeline against the required windows, and the policy naming who is accountable. Moderate requires monthly operating system, database and web application scanning, with high findings remediated in thirty days, moderate in ninety, and low in one hundred and eighty. That cadence is a standing operational commitment, not a project.
The single highest-return engineering investment here is evidence automation. Build the pipeline that produces the artifact on a schedule rather than assigning a person to gather screenshots each month. Companies that skip this discover that continuous monitoring costs them a full-time role forever. Companies that build it spend three engineer-months once and then produce a monthly package with a job.
OSCAL is the standard worth adopting early. NIST's Open Security Controls Assessment Language expresses system security plans, control implementations and assessment results in machine-readable form, and FedRAMP is moving toward it as the native format. Writing your SSP as structured data rather than a four-hundred-page Word document changes the maintenance cost of every subsequent year.
What a commercial SaaS team already has, going in
Editorial estimate of how often a mid-size commercial SaaS team already holds each item in assessable form at the start of a federal effort. Illustrative, not a measured statistic.
The three requirements that surprise engineering teams
FIPS 140-3 validated cryptography. Using TLS 1.3 is not the requirement. The requirement is that the cryptographic module performing the operation appears on the NIST Cryptographic Module Validation Program list. Most managed cloud services in a government region satisfy this. Application-level encryption written against a general-purpose library frequently does not, and the fix means either moving the operation into a validated module or switching to a provider service that already holds validation.
Personnel screening. Controls in the PS family require that people with privileged access to the system be screened at a level appropriate to their access. In practice this means background investigations for administrators, and for some agency deployments it means US persons only for operational roles. A distributed engineering team with production access spread across several countries has an org-chart problem, not a software problem, and the answer is a separate on-call rotation staffed by a defined group.
Third-party dependencies come with you. Every external service inside your boundary is in scope. Your error tracker, your feature flag service, your analytics, your email provider, your log aggregator. Each one either holds its own FedRAMP authorization, is replaced by something that does, or is removed from the government deployment path. This audit is usually the moment a team realizes how many vendors touch production, and it typically produces a list of fifteen to forty services with maybe a third of them authorized.
Section 508 is a real gate and it is usually late
Section 508 of the Rehabilitation Act, implemented through the Revised 508 Standards that incorporate WCAG 2.0 Level AA by reference, applies to any information and communication technology a federal agency procures. Agencies request an Accessibility Conformance Report, generally on the VPAT template maintained by ITI. A vendor whose VPAT is full of "supports" claims an evaluator can disprove in ten minutes has damaged its credibility on everything else.
The realistic path is an audit against WCAG 2.1 AA, a remediation plan for the gaps, and an honest conformance report that says "partially supports" with specifics and a fix date where that is true. Remediation on a mature single-page application typically runs two to four months of front-end work. Starting it after the contract conversation begins is the common sequencing error.
The contract vehicle question, answered simply
Agencies cannot easily buy from a company with no vehicle. The three realistic first paths are a GSA Multiple Award Schedule contract under the IT category, a subcontract to a prime or integrator who already holds a vehicle, or a direct award below the simplified acquisition threshold for a small pilot. A Schedule contract takes roughly six to twelve months to obtain and requires commercial sales history and Commercial Sales Practices disclosure. The subcontract path is far faster and is how most software companies book their first federal revenue.
For a product with genuine technical novelty, SBIR and STTR are a separate and underused door. A Phase I is a small research contract with no vehicle required, and a Phase III award can be sole-sourced by any agency for work deriving from the earlier phases, with no dollar or duration limit. Other Transaction Agreements, particularly through consortia, are another route where a nontraditional defense contractor can contract without carrying the full FAR apparatus.
A sequence that works
The order matters more than the speed. Find the sponsoring agency before spending on the authorization, because an authorization without a sponsor is a package sitting in a queue. In parallel, draw the boundary and stand up the separate government environment, because that work is on the critical path for everything downstream and it does not depend on the sponsor.
Then run a readiness assessment against the Moderate baseline and produce an honest gap list. Fix the infrastructure gaps, build the evidence automation, and only then engage the 3PAO. Engaging an assessor before the gaps are closed converts an assessment into an expensive consulting engagement with a stranger. Run the Section 508 audit concurrently, since it shares no resources with the security work. Pursue the vehicle in parallel with everything, because its clock runs independently.
A company that sequences this well is looking at twelve to sixteen months and a defined budget. One that starts with the assessor, or draws the boundary around all of production, is looking at twice that and a demoralized team. The difference is entirely front-loaded decisions.
Bottom line
The change a commercial SaaS company has to make is architectural, not commercial. A separate deployment with a tightly drawn boundary, an evidence pipeline that runs on a schedule, a dependency list you have actually audited, an accessible interface, and a contract path that exists before the customer needs it. None of that requires rewriting the product. All of it requires deciding early, in the right order, with someone in the room who has produced these artifacts before and knows which control language an assessor will push back on.
Frequently asked questions
No. You need it before an agency can put its data in your system. Conversations, pilots on synthetic data, and subcontract work through a prime who already holds an authorized environment all happen earlier. Many companies book their first federal revenue that way while the authorization is in progress.
Twelve to eighteen months is the common range once a sponsoring agency is committed. Companies with mature infrastructure as code, centralized logging and a documented change process land at the low end. Companies building those practices during the process land well past the high end.
Technically possible, usually a poor trade for a first authorization. Logical separation pulls every shared component into the assessment boundary, which puts your commercial release cadence under federal change control. A separate account or subscription costs more in infrastructure and far less in organizational friction.
FedRAMP is the government-wide authorization program. The DoD Cloud Computing SRG layers Impact Levels on top for defense data. IL4 covers CUI and generally requires FedRAMP Moderate as a floor plus additional DoD-specific requirements. IL5 adds dedicated infrastructure separation for National Security System information.
Often yes. The control set derives from the same 800-53 baselines, the cost and timeline are meaningfully lower, and the resulting environment and documentation carry forward. For a company testing whether public-sector revenue justifies the investment, it is a real proving ground rather than a detour.