What this is for
FedRAMP Moderate is the security baseline a SaaS provider has to meet to sell to most US federal agencies. It is 325 controls, organized into 17 families (Access Control, Configuration Management, Incident Response, and so on), each with detailed implementation requirements drawn from NIST SP 800-53.
If you are at a startup looking at federal customers, the standard advice is to buy a GRC platform. The pitch is reasonable: 325 controls is a lot, the documentation requirements are real, and the platforms generate the deliverables. The problem is that those platforms cost $30K to $100K a year and assume you have already decided to pursue FedRAMP. Before that decision, you usually want a credible readiness statement: where are we today, what is the gap, how long would it actually take.
You can get to that statement on a laptop, in a few weeks, for the cost of your time.
The toolchain
Three pieces, all open or free.
1. The official OSCAL catalogs from NIST as the source of truth.
NIST publishes the SP 800-53 catalog and the FedRAMP Moderate baseline in OSCAL, a JSON and XML format for machine-readable control content. This is non-negotiable. Any other source (vendor PDFs, blog summaries) will drift, and you will end up debating which version of a control statement is correct rather than implementing it. Pull straight from the NIST repos and you have one canonical text.
2. A markdown-per-control directory in git.
One file per control, named by the control ID. Each file has the same template: control statement (pulled verbatim from OSCAL), implementation narrative (written by you), parameter values (the tailoring decisions FedRAMP requires), assessment method, responsible role.
Why git: every change to a control is a diff. When a control moves from 'Partially Implemented' to 'Implemented' you can see exactly which words and decisions changed, who made the change, and when. This is the audit trail the actual audit will eventually ask for, and you got it for free by using version control.
Why markdown: it renders in GitHub for review, it diffs cleanly, and a small script can compile it back into the SSP format the auditor expects.
3. A small CLI that renders the SSP.
A hundred lines of Python or TypeScript reads the markdown directory, applies the parameter values, and writes out either a Word document or an OSCAL-format SSP. Most CLIs of this kind already exist in the OSCAL ecosystem; you can also write your own in an afternoon. The point is that the SSP is generated from the markdown, not the other way around, so the markdown is the source of truth and the document is a build artifact.
What this is not
This is not a GRC platform. There is no workflow engine, no evidence repository, no continuous monitoring dashboard. If you are actually going through an authorization, you will probably want one of those eventually.
But it is enough to get to a credible readiness statement without paying for one. That statement is what unlocks the conversation with your prospective federal customer, the leadership decision to pursue FedRAMP for real, and the budget for the platform you actually need.
Who this is for
Founders deciding whether to chase a federal pilot. Security engineers who have just been told to 'look into FedRAMP' and have no team. Internal auditors at firms whose first FedRAMP engagement is six months out and who want a working artifact to point at when the project kicks off.
If you are already in a FedRAMP authorization, this is too lightweight. Go buy the platform.