Selling to the US public sector: FedRAMP against SOC 2, honestly

A prospect in a federal agency says they need FedRAMP. The sales team relays it to engineering as "like SOC 2 but for government". Six weeks later someone has read the baseline, the number of controls has a comma in it, and the conversation turns into whether this deal is worth restructuring the company around.

Often it is. Sometimes it is not, and the ability to tell the difference early is worth more than any control implementation.

The structural difference

SOC 2 is an attestation. You define your system, you select which of the five trust services criteria apply, you write the controls you believe meet them, and a licensed CPA firm you hire tests whether you did what you said. Two organisations with the same product can have very different SOC 2 reports and both be legitimate, because you choose the controls.

FedRAMP is an authorisation against a prescribed baseline. The controls come from NIST SP 800-53, tailored into low, moderate and high baselines. You do not choose them. A third-party assessment organisation, accredited for this purpose, tests them, and a government body grants an authority to operate. The output is not a report you hand to a buyer; it is a listing in a marketplace that agencies can consume.

That single difference drives everything else. SOC 2 scales with how complicated your system is. FedRAMP scales with a fixed, externally set list that has hundreds of controls at the moderate baseline and considerably more at high.

What each actually costs

For SOC 2, a Type II in a small-to-medium SaaS company typically means a few months of readiness work, an observation window of three to twelve months, a five-figure audit fee, and perhaps a quarter of one person's ongoing time. Compliance automation tooling reduces the evidence collection burden meaningfully. The sequencing decision is covered in SOC 2 Type I or Type II, and the evidence machinery in automating SOC 2 evidence.

For FedRAMP moderate, plan on a multi-year programme. The assessment fee alone is several times a SOC 2 audit. Beyond that you are usually funding: a dedicated compliance function, a separate cloud environment that satisfies the boundary requirements, continuous monitoring with monthly deliverables, significant engineering work on the controls that do not fit a normal SaaS architecture, and the sponsor relationship itself. Public estimates for the total vary widely and the honest framing is that it is a seven-figure commitment for most companies once internal time is counted.

The recurring cost is the part teams underestimate. Authorisation is not a finish line. Continuous monitoring means monthly vulnerability scans with defined remediation windows, ongoing plan-of-action tracking, and a significant change process where meaningful architectural changes require review before you make them. Engineering velocity in the authorised boundary changes permanently.

The paths in, and why sponsorship matters

The traditional route is agency sponsorship: an agency that wants your product sponsors you, and the authorisation they grant can then be reused by other agencies. This is the most common path and it means the commercial conversation comes first. Without a sponsor, you are building for a market that has not committed.

There has historically also been a programme-level authorisation route through the FedRAMP board, which is more selective and has been used for widely demanded services. The programme has been undergoing modernisation, with work on automating assessment and reusing evidence, so the specifics of the available paths and their names change. Check the current programme documentation rather than a summary written two years ago.

StateRAMP, now operating under a broader name, applies the same model at state and local level, and there are reciprocity arrangements worth understanding if that is your buyer. DoD impact levels sit above FedRAMP for defence workloads and add further requirements.

The architectural decisions FedRAMP forces

This is where engineering learns the cost is not only paperwork.

The authorisation boundary. Everything inside it is in scope, including every external service the system connects to. Each third-party dependency must either be independently authorised, be brought inside the boundary, or be justified. That routinely eliminates SaaS tools a normal engineering organisation takes for granted, for monitoring, error tracking, support and analytics.

Government cloud regions. Moderate and above generally means running in the provider's government-specific regions, which have a smaller service catalogue, later feature availability and different pricing. Code written against a commercial region does not always run unchanged.

Personnel requirements. Certain roles require US persons and background screening for support access. For a distributed engineering team this can mean a separate support rota, which is an organisational change rather than a technical one.

FIPS-validated cryptography. Not merely "we use TLS", but validated modules, which constrains libraries, runtimes and sometimes managed service choices.

Separate environment. In practice most companies end up running a separate instance of their product for the government boundary, because applying the full baseline to the commercial environment is worse. That means two deployment targets, two pipelines and a permanent divergence risk.

Where the work overlaps

The overlap is real and worth exploiting, even though it is smaller than vendors suggest.

If you hold ISO 27001 or SOC 2, your management system, risk process, access control, change management, incident response and vendor management are largely reusable as evidence. The gap is depth and prescriptiveness: FedRAMP asks for specific configurations and specific documented artefacts where SOC 2 accepts your own reasoned control.

Treat it as one control set with several mappings, which is the argument in one control set across frameworks, and apply the same discipline that makes it sustainable: controls implemented as policy in code, evidence generated automatically, and a Statement of Applicability habit for recording which control applies and why, as in the Statement of Applicability.

For a European company, the comparison worth making is with the national schemes: the effort profile of FedRAMP is closer to a full ENS certification at a high category than to SOC 2, in that the control set is prescribed rather than chosen.

When the answer is not yet

Say no, or not yet, when: you have no sponsoring agency and no committed pipeline; your architecture depends heavily on SaaS tools that are not authorised; your team is small enough that a dedicated compliance function would consume a meaningful fraction of engineering; or the addressable federal revenue does not clearly exceed the multi-year programme cost.

The intermediate positions are genuinely useful. Publish a SOC 2 Type II. Map your controls to the NIST baseline and publish the gap analysis, which some buyers accept as evidence of direction. Sell through a partner or a marketplace reseller who already holds an authorisation. Target state and local buyers first, where the equivalent programme is a smaller lift.

What to do this week

Take the moderate baseline control list and mark each control as already met, partially met or not started, using your existing SOC 2 or ISO evidence. It is a day of work with someone who knows your controls. The percentage in the third column is the honest size of the programme, and it is the number to put in front of the leadership team before anyone answers the prospect. We run that gap analysis in the scoping phase of a security engagement.