Readiness Plan — Reaching 80% FedRAMP Moderate
This plan covers both the docs documentation set and the p3-deploy platform (the p3cli binary, soon rebranded m3). It is the result of a three-part audit: the ATO template set, the engineering-practices control mapping, and the platform code and its own docs. The goal is a measurable, defensible path to 80% FedRAMP Moderate readiness.
The picture in one paragraph
There are two compliance assets at very different maturity levels, and they do not yet reference each other. The docs set is a strong planning scaffold — roughly 50% of Moderate documentation readiness, but only 15–20% of assessment readiness. The p3-deploy CLI is a real, working evidence collector and GitHub governance enforcer, but its own compliance docs describe a p3cli compliance and p3cli audit command suite that does not exist. The fastest path to “reads ATO-friendly” is less about writing more and more about closing drift, claiming what the platform already does, and wiring the three pieces together.
Current-state scorecard
| Asset | What is strong | What undercuts it |
|---|---|---|
docs/compliance/ato templates | POA&M discipline, correct status and inheritance vocabulary, official-package crosswalk, explicit honesty rule | No completed FIPS-199, no boundary or data-flow diagram, control narratives are family-level not per-control |
docs/engineering-practices mapping | ato-control-alignment.mdx cites real control IDs and the CM family is genuinely defensible | Prior status numbers drifted across files, zero enhancement coverage, no control owners named, runbooks carry no control IDs |
p3-deploy (p3cli) | evidence collect/verify/archive with SHA-256 manifests, Trivy security scan, git governance for branch protection and rulesets, fedramp.yaml AWS evidence harvester mapped to ~34 controls | Compliance docs are fictional or stale, security scan is never called in CI, require_signed_images and require_sbom flags are dead, no SBOM or cosign, two disjoint evidence systems |
Decision 0 — Confirm the target program
The current docs target federal FedRAMP Agency Authorization, but M3 is Maryland Digital Service. For a Maryland state system the relevant regime is most likely StateRAMP or GovRAMP (which carries FedRAMP reciprocity), possibly with CJIS or IRS-1075 overlays depending on the data handled.
This plan executes against FedRAMP Moderate as requested. The control work is approximately 95% identical either way, so none of it is wasted — the program choice mainly changes the package banner and the authorizing path. Confirm the target before the per-control statements are written.
What “80% complete” means here
Define the target precisely so it is measurable and defensible.
80% means 80% of the FedRAMP Moderate base controls (~325) have a per-control implementation statement with: status, control origination, a named owner, and an evidence pointer that resolves to a real artifact — anchored to a completed FIPS-199 categorization and a defined authorization boundary.
By that definition the current state is roughly 20–25%: CM is strong, AC, AU, IR, SA, and SC are partial, everything else is thin or absent, and enhancement coverage is 0%.
Phase 0 — Stop the bleeding
One week of cheap, high-credibility work. These are the items that currently read as not ATO-friendly.
| Work Item | Outcome | Owner | Exit Criteria |
|---|---|---|---|
| Rewrite the fictional p3-deploy compliance docs | Docs match the real CLI surface | Platform Engineering | FEDRAMP_COMPLIANCE.md, COMPLIANCE.md, and docs/examples/compliance-config.yaml describe only real commands: evidence, security scan, registry compliance, git governance |
| Reconcile the readiness percentages | One defensible status number | Security | ato-control-alignment.mdx and roadmap/ato-readiness.mdx cite the same figure with a documented computation |
| Make the dead config flags honest | Config does not lie | Platform Engineering | require_signed_images and require_sbom are either enforced or removed |
Relocate compliance-notes.mdx | No Storybook link report mistaken for compliance content | Documentation | File moved or renamed out of the ATO-adjacent path |
Why the fictional docs matter most
p3-deploy/docs/FEDRAMP_COMPLIANCE.md and docs/COMPLIANCE.md document p3cli compliance ... and p3cli audit ... commands that do not exist, and a p3.compliance.* config schema already deprecated in pkg/config/human_metadata.go. To an assessor this is worse than missing docs, because it shows the package describing capabilities the system does not have.
Phase 1 — Build the authorization spine
Two to four weeks. Nothing downstream is real until these exist. The compliance/ato/templates/ folder already holds the shells; they need to be populated.
| Work Item | Outcome | Owner | Exit Criteria |
|---|---|---|---|
| Complete FIPS-199 categorization | The Moderate baseline is justified, not assumed | Security | C/I/A impacts set, high-water mark recorded, rationale approved in templates/02 |
| Define boundary and data flows | Assessment scope is unambiguous | Platform Engineering | Authorization boundary diagram and data-flow diagram reviewed |
| Name the humans | Accountability is visible | System Owner | AO, ISSO/ISSM, System Owner, and per-control owners named |
| Stand up the “-1” policy controls | Each family has a policy and procedure | Security | AC-1, AU-1, CM-1, CP-1, IA-1, IR-1, and the rest exist as controlled documents |
The boundary and data-flow diagrams are the single most important gap — the docs themselves flag an unclear boundary as the top authorization risk. A draft Mermaid C4 plus trust-boundary sketch reads far more ready than a sentence promising one.
Phase 2 — Make the platform produce control evidence automatically
This is where the tool turns documented controls into evidenced controls.
| Work Item | Outcome | Owner | Exit Criteria |
|---|---|---|---|
Wire security scan into CI | RA-5 and SI-2 evidence on every deploy | Platform Engineering | p3cli security scan image runs in p3-deploy.yaml and its report is a required artifact |
| Add cosign signing and syft SBOM | SI-7, SR-3, SR-4 supply-chain integrity | Platform Engineering | Images signed, SBOM emitted, both captured by evidence collect |
| Add a scheduled ConMon workflow | CA-7 continuous-monitoring trail | Security | on: schedule: job runs scan plus evidence collect and archives to durable storage |
| Add a POA&M generator | A living POA&M from real findings | Security | A formatting pass over security-*.json and registry-compliance.json emits POA&M Markdown or CSV |
| Unify the two evidence systems | One auditor-facing evidence format | Platform Engineering | evidence archive ingests the fedramp.yaml evidence tree and adopts its KMS-signed bundle pattern (AU-9) |
Phase 3 — Convert the doc set to an SSP
The bulk of the percentage gain lives here.
| Work Item | Outcome | Owner | Exit Criteria |
|---|---|---|---|
| Write per-control implementation statements | The full Moderate baseline, not the ~70 key controls | Security | Each control has status, origination, responsible role, and a per-part response |
| Claim inherited controls explicitly | Free coverage for cloud-provided controls | Security | Inheritance designation converts the ~22 PE controls and parts of SC/CP/MA/MP to “Inherited — AWS FedRAMP Moderate” |
| Wire runbooks into the control map | The “how” behind each evidence artifact is linked | Documentation | runbooks/tools/github/* and platform runbooks carry ato_controls frontmatter and are referenced by the alignment file |
| Build out the forgotten families | AT, PS, MA, MP gain real coverage | Security | Training records, screening and termination procedures, maintenance windows, and media protection pages exist |
The forgotten families (AT, PS, MA, MP) are low engineering effort and high control count, and an assessor will not waive them. They are the classic blind spot for an engineering-led ATO.
Phase 4 — Enhancements and named-gap closure
| Work Item | Outcome | Owner | Exit Criteria |
|---|---|---|---|
| Cover Moderate-required enhancements | Strong families actually reach Moderate | Security | AC-2(1–4), AU-6(1)(3), CM-6(1), IA-2(1)(2)(8)(12), SC-7(3–8), CP-9(1) addressed |
| Resolve the four open technical POA&Ms | Known high-risk gaps closed | Security | FIPS-140-3 validation, vuln-scan scope, release signing/SBOM, and audit-log retention all resolved |
| Publish RTO/RPO and run a restore test | CP-9 and CP-10 move from policy to evidence | Platform Engineering | Per-service RTO/RPO published and first quarterly restore-test artifact produced |
| Defer OSCAL export | Packaging follows a stable evidence model | Security | Revisited only after owners and evidence model are stable |
If you only do five things
- Rewrite the fictional p3-deploy compliance docs to match the real CLI. This restores credibility.
- Complete FIPS-199 and draw the boundary and data-flow diagrams. This unblocks everything else.
- Wire
security scan, SBOM, and cosign into CI, plus a scheduled ConMon job. This puts evidence on autopilot. - Write per-control implementation statements for the full Moderate baseline with origination and owner. This is the actual percentage gain.
- Claim inherited controls and wire the runbooks into the control map. This is free coverage plus the missing “how.”
Two decisions to confirm
| Decision | Why it matters | Default taken in this plan |
|---|---|---|
| Program target | FedRAMP Moderate vs Maryland StateRAMP/GovRAMP changes the package banner and authorizing path | FedRAMP Moderate, per the original request |
| Sequencing | Phase 0 is low-risk and pure credibility; later phases need owners assigned first | Phase 0 can start immediately; Phase 1 begins once owners are named |