Home / Sectors / Cloud Service Providers
Get certified, stay certified, keep shipping.
FedRAMP Moderate and High certification, DoD IL-5 and IL-6 uplift, and continuous monitoring programs built to survive assessment rather than to look complete on paper.
Certification gets you listed. It does not get you a customer.
A FedRAMP certification puts your service in the Marketplace. Every agency that then wants to use it still issues its own Authorization to Operate or Authorization to Connect against your package. That decision turns almost entirely on how much residual work you are handing them.
Which makes the Customer Responsibility Matrix the most commercially consequential document you will produce. Every control marked customer responsible is work an agency has to complete before it can say yes to you. A CRM written to minimise your assessment effort will quietly lengthen every sales cycle that follows it.
The boundary is a product decision
Where you draw it sets your engineering scope permanently. Draw it wide and you own more controls, more continuous monitoring and more significant change notifications forever. Draw it narrow and your customers inherit that work instead, which shows up as friction in procurement rather than in your backlog.
This is worth deciding deliberately, with engineering in the room, before a single control implementation statement is written. Boundaries redrawn after assessment invalidate the evidence built against them.
Rev5 or 20x, while both are live
There is no general answer. FedRAMP 20x rewards providers who already ship with mature DevSecOps, machine-readable evidence and automation, and it punishes those who do not by exposing the gap immediately. Rev5 under CR26 remains the realistic path for most existing certification holders, and CR26 changed enough about maintenance that treating it as business as usual is its own risk.
The question we start with is what your agency customers are asking for and what your architecture can actually support. Those two answers usually settle it.
Failure modes
Where providers actually lose the assessment.
Rarely on a control nobody implemented. Almost always on the relationship between what the package claims and what the system can show.
| Failure | What it looks like on assessment day |
|---|---|
| Boundary drift | Components added to the service after the boundary was set, never rescoped, and discovered by an assessor reading a current architecture diagram. |
| Inherited controls | Controls claimed from the underlying platform without the inheritance evidence to support the claim. A certified IaaS covers a meaningful share of the baseline, but only the share you can actually demonstrate. |
| CRM drift | Responsibilities assigned to the customer in the matrix that the customer was never told about, surfacing during their own authorization rather than during yours. |
| Evidence freshness | Artifacts generated for the assessment rather than by the system. It reads as a compliance exercise because it is one, and it does not survive the following year. |
| Significant change | Changes shipped without a significant change notification, found at annual assessment, with the remediation cost multiplied by however long ago they shipped. |
Next step
Tell us what you hold today and what your agency customer expects next.
It starts with a gap analysis at no cost, and a scoped proposal follows.