The budget line nobody writes down
A commercial software company decides to pursue FedRAMP and builds a budget. It has three lines on it: the independent assessor, an advisory firm to help produce the documentation, and some allowance for tooling. The three add up to a number a CFO can approve, and the program gets a green light. Eight months later the company is over schedule, the platform team has shipped almost nothing customers asked for, and nobody can explain where the time went. The budget was not wrong about the vendors. It was silent about the only resource that was actually scarce.
FedRAMP is an assessment of a running system against NIST SP 800-53 controls, followed by a government decision to accept whatever risk remains. The documents are a description of the system. If the system does not already do what the description would have to claim, somebody writes code. That somebody is your senior platform engineer, and every hour they spend on it is an hour not spent on the thing your paying customers renew for.
So the honest unit of measure is engineering hours, not dollars paid to outsiders. What follows is where those hours go, in rough order of size, based on what the work actually consists of rather than what a proposal template says about it.
Why the assessor invoice misleads you
An independent assessment for a mid-sized SaaS platform tends to land somewhere in the range of $150,000 to $400,000, depending on system complexity and the assurance level you are pursuing. Advisory support to produce and maintain the package runs somewhere similar over the life of the effort. Those are real numbers and they are usually quoted accurately.
They mislead because they are the price of being measured, not the price of passing. An assessor arrives, looks at your system, and writes down what is true. If centralized logging is not in place when they arrive, they record its absence. They do not build it. Neither does the advisory firm, in most engagements, because writing a system security plan and writing Terraform are different jobs staffed by different people at different rates.
Which leaves the remediation gap sitting entirely on your own team. For a company that built its product for commercial customers and never had a reason to satisfy a federal control catalog, that gap is typically between 4,000 and 12,000 engineering hours for a first authorization. At a fully loaded cost of $120 to $180 per hour, the internal number quietly exceeds every external invoice combined, and it arrives as missed roadmap rather than as a line item anyone approved.
Where the engineering hours go — first authorization, typical commercial SaaS
Relative weighting from the control families that most often drive rework in commercial platforms. Illustrative ranking, not a measured statistic.
Logging is the single largest line, and it is not a logging problem
Every first-time vendor underestimates the AU control family. The reason is that they already have logs. Application logs go to a hosted search tool, infrastructure logs go somewhere else, and the team can find what it needs during an incident. That feels like a solved problem.
The control catalog asks for something different. It asks which events are audited and why that list is sufficient, whether the record contains enough to establish what happened and who did it, whether the logs are protected from the administrators whose actions they record, how long they are retained, and whether anyone reviews them on a defined cadence and can prove it. AU-6 in particular is where teams lose weeks, because review and reporting is a process with an artifact, not a dashboard somebody could open.
The engineering work behind that is real. Instrument the events that are not currently emitted. Normalize records that were written for humans reading them during an outage into a schema that supports correlation. Move storage somewhere the platform team cannot silently alter. Wire alerting to specific conditions rather than to volume. Then build the reporting that shows the review happened. Two engineers for two to three months is a common outcome, and the honest framing is that most of it is observability work the company would have benefited from anyway.
Identity is where the architecture argument happens
The AC and IA families force a question most commercial products have deferred. Who can reach production, through what path, with what authentication, and can that be shown after the fact rather than asserted.
Startups typically run on a shared identity provider, generous engineer access to production for debugging, and a break-glass credential in a password manager. Each of those becomes a finding. Least privilege has to be implemented rather than intended. Privileged actions need separate credentials and phishing-resistant multi-factor. Session termination, account review cadence and automated deprovisioning all need to exist as mechanisms with evidence behind them.
The expensive version of this is when a product was built with a single administrative role because the customer base never needed more. Splitting one role into a real permission model touches the data layer, the API surface, the front end and every integration test. That is a product change, priced like a product change, and it is the most common reason a FedRAMP program slips two quarters.
The boundary decides the price before anything else does
The authorization boundary is the set of components inside the assessment. Everything inside gets controls applied, evidence collected and findings tracked. Everything outside does not. That single drawing does more to determine total hours than any other decision in the program, and it gets made in a hurry by people who have not yet learned what it costs.
The costly instinct is to submit the production environment as it stands. The cheaper design is a separate deployment with only the components the federal offering requires, sharing a code base with the commercial product but not sharing a tenancy, an identity plane or a data store.
The reason that separation pays for itself is third-party dependencies. Every external service inside the boundary must itself be authorized or you inherit the burden of showing equivalence. A commercial platform typically carries a long list of these: analytics, error tracking, session replay, support chat, feature flags, a transactional email provider, a payment processor. Each one becomes a decision to replace it, exclude it, or defend it. Replacing an error tracker in a running product is a week. Doing it seven times, under schedule pressure, while the assessor waits, is a quarter.
| Dependency inside the boundary | What it costs to keep | Cheaper move |
|---|---|---|
| Error and crash reporting | Stack frames routinely carry customer data, which puts the vendor in scope for the data it holds | Self-hosted collector inside the boundary, or strict scrubbing proven by test |
| Product analytics and session replay | Hard to defend, and rarely worth the control work for a federal tenant | Disabled in the federal deployment by build configuration, not by a setting |
| Support chat widgets | Third-party script in an authenticated page, plus a separate data processor | Removed from the federal build entirely |
| CI/CD and artifact registry | Builds production artifacts, so supply chain and integrity controls follow it | Keep it, but design the pipeline for evidence from the start |
| Managed database and object storage | Only defensible on an authorized cloud service, and encryption requirements apply | Choose services already listed rather than arguing equivalence |
Vulnerability management becomes a standing tax
The RA and SI families turn patching from a background activity into a scheduled obligation with deadlines and reporting. Scans run on a defined cadence across operating systems, containers, application code and databases. Findings get triaged against required timelines, and anything not fixed in the window becomes a tracked item with a remediation plan a government reviewer reads.
What surprises teams is that the work does not stop when the authorization is granted. It becomes permanent. Deferring a dependency upgrade because it is disruptive stops being a judgment call and becomes an entry somebody has to explain. Most vendors end up dedicating between a quarter and a half of one engineer to this indefinitely, which is a hiring decision rather than a project cost.
The lever here is automation built early. A team that wires scanning into the pipeline, auto-files findings with correct severity and due dates, and generates the monthly report from the tracker spends a fraction of what a team doing it by hand each month spends. That build is a few weeks of work and it repays itself within the first year.
How much of the recurring effort survives after authorization
Relative share of steady-state effort. Automation shifts the top two lines the most. Illustrative ranking, not a measured statistic.
Evidence is a data pipeline, and treating it as one changes the number
The reason FedRAMP feels heavier than commercial security work is not the control count. It is that every control needs evidence, on a schedule, in a form a reviewer accepts, forever.
Companies that treat this as an administrative chore assign it to a program manager who chases screenshots each month. That approach works for one cycle and degrades from there, because screenshots go stale, the person who took them leaves, and nothing catches drift between collections.
The version that costs less over three years treats evidence as a data pipeline. Configuration state comes from the infrastructure-as-code layer. Access reviews come from a query against the identity provider. Vulnerability posture comes from the scanner API. Change records come from the ticket system. Each artifact is generated, timestamped and stored automatically. The initial build is perhaps 400 to 800 hours. It removes most of the recurring drag, and it is the clearest signal to a reviewer that the described system is the running one.
The FedRAMP program has been moving in this direction, with machine-readable package formats and automated validation replacing narrative-heavy submissions. A vendor already producing structured evidence is aligned with where the program is going rather than retrofitting later.
Where hours disappear without producing anything
Three categories of waste show up in nearly every first attempt.
Documentation written before the system settled. A system security plan describing an architecture that then changes has to be rewritten, and control narratives are slow to write. Teams that document first and build second frequently pay for the same 600 pages twice.
Interview and evidence-request overhead. Assessors interview engineers and request artifacts. Each request seems small. Across an assessment window the accumulated interruption on senior staff commonly reaches 300 to 600 hours, and it lands on exactly the people whose focus you were protecting.
Findings that were architectural. A finding that requires a design change during assessment is the most expensive kind, because it arrives when the schedule has no slack. This is what a readiness review is for, and skipping one to save a few weeks reliably costs more than it saved.
A realistic model for the first authorization
For a commercial SaaS platform of moderate complexity pursuing its first authorization, the shape of the effort tends to look like this. Boundary definition and readiness assessment, 200 to 400 hours. Control implementation and remediation, 3,000 to 8,000 hours. Documentation, 800 to 1,500 hours. Evidence automation, 400 to 800 hours. Assessment support, 300 to 600 hours. Post-assessment remediation, 500 to 1,500 hours.
Total internal engineering effort lands between roughly 5,000 and 13,000 hours, spread across twelve to twenty months. Loaded, that is $600,000 to $2,000,000 of internal cost, on top of the external invoices. A team of four working most of a year is the honest picture.
The spread is wide because it depends almost entirely on how far the existing architecture sits from the requirements. A platform already running on an authorized cloud service, with infrastructure as code, centralized logging and a real permission model, lands near the bottom. A platform with manual deployments, shared credentials and a decade of third-party integrations lands near the top or above it.
What actually reduces the number
Four decisions move the total more than anything else, and all four are made before the program starts.
Draw the smallest defensible boundary. A separate federal deployment with fewer components almost always beats submitting the commercial environment, even counting the cost of running two.
Inherit everything you can. Building on an already-authorized cloud service transfers a substantial share of the physical, environmental and infrastructure controls to the provider. Read the customer responsibility matrix before you design, not after.
Automate evidence from day one. The pipeline is cheaper to build than the manual process is to run, and it does not decay.
Do the readiness review honestly. The gap analysis that finds architectural problems early is the highest-return activity in the entire program. Findings discovered before the assessor arrives are engineering tasks. The same findings discovered during assessment are schedule failures.
Bottom line
FedRAMP is an engineering program with a compliance deliverable attached, and companies that budget it the other way around are surprised twice: once by the size of the internal effort, and again when continuous monitoring turns out to be permanent. Price the engineering hours honestly, draw the boundary before you draw the budget, and build the evidence pipeline while you build the controls. The vendors you pay are the visible cost. The roadmap you postpone is the real one, and it is the only part of this you can still change.
Frequently asked questions
For a moderate-complexity commercial SaaS platform, roughly 5,000 to 13,000 internal engineering hours across twelve to twenty months. The spread is driven by how far the current architecture sits from the control requirements, not by the size of the customer base.
They produce documentation and perform the assessment. Neither builds the logging pipeline, splits the permission model, or replaces a third-party dependency. That remediation work stays with your engineering team unless you hire a firm specifically to build it.
Audit and accountability first, then access control and identification, then configuration management. Logging is consistently underestimated because teams already have logs and assume the requirement is satisfied. The requirement is about protected, reviewable, retained audit records, which is a different system.
No. Continuous monitoring is ongoing: scheduled scanning, tracked remediation timelines, periodic reporting and change notification. Most vendors dedicate a quarter to a half of an engineer permanently. Automation built during the initial effort is what keeps that fraction small.
The boundary. A separate, minimal federal deployment removes whole categories of third-party dependency work before it starts. Building it on an already-authorized cloud service inherits a large share of infrastructure controls rather than requiring you to implement and evidence them.