The ISV journey: where Efterlev fits FedRAMP 20x¶

If you're an Independent Software Vendor (ISV) pursuing your first FedRAMP authorization via FedRAMP 20x, the path has seven stages. This page maps each stage, says plainly who does the work, and shows where Efterlev helps — and, just as importantly, where it does not.

Read this if you're trying to answer "where am I, what's next, and which parts can a tool do for me?"

For the RFC-by-RFC artifact mapping, see rfc-mapping.md. For what Efterlev deliberately is not, see What Efterlev is not.

The one-sentence version¶

Efterlev is an engineering-readiness and pre-submission tool. It turns your infrastructure-as-code and runtime evidence into a reviewer-ready, provenance-tracked draft of your KSI posture. It does not grant authorizations, act as a 3PAO, or replace the human review every artifact requires.

Status badges¶

Consistent with rfc-mapping.md:

Badge	Meaning
🟢 Strong	Efterlev does substantial, default-on work at this stage.
🟡 Partial	Efterlev helps, but the bulk of the stage is human/operational.
🔵 Planned	On the roadmap; named release below.
⚪ Out of scope	Not Efterlev's job — agency-side, assessor-side, or policy.

Stage 0 — Strategic: decide to pursue 20x¶

What happens: You decide whether to pursue FedRAMP, pick your impact level (Low / Moderate / High), choose the path (FedRAMP 20x vs the Rev 5 process), and draw a first sketch of your authorization boundary.

Who does it: Your leadership + a compliance lead, often with a consultant or advisor.

Where Efterlev fits: 🟡 Partial. Efterlev assumes you've decided on 20x Class C (Moderate) — that's the default baseline. Three things help you orient before you've scanned anything:

efterlev plan maps the KSI landscape before you scan: with no workspace, no IaC, and no API key, it shows how many KSIs Efterlev evidences automatically from your infrastructure, how many need a human-authored Evidence Manifest (the procedural ones — personnel, training, incident response), where the human work concentrates by theme, and — for a chosen architecture — which KSIs are commonly CSP-inherited under shared responsibility. Deterministic; it's a map, not a scan.
efterlev init scaffolds a workspace for a chosen baseline and writes a [boundary] scope you can refine.
The FAQ and What Efterlev is not pages frame the 20x-vs-Rev5 decision honestly.

Honest gap: Efterlev does not (today) walk you through the 20x-vs-Rev5 decision interactively or recommend an impact level — that's advisory work. And it deliberately does not estimate a calendar timeline: efterlev plan expresses effort in KSI-work units, never "days to authorization" (Efterlev measures tool scope, not the authorization process).

Stage 1 — Engineering readiness: meet the KSIs¶

What happens: You configure your system so that it actually satisfies the FedRAMP 20x Key Security Indicators (KSIs) — encryption, network isolation, MFA, logging, and so on — and you assemble the evidence that proves it.

Who does it: Your engineering team. This is where the bulk of the real work lives, and it's the stage Efterlev was built for.

Where Efterlev fits: 🟢 Strong. This is the core loop:

Step	Command	Output
Scan IaC for evidence	`efterlev scan`	Evidence records (Terraform, CloudFormation, Python CDK, GitHub workflows)
Ingest runtime evidence	`efterlev import-security-hub` / `import-config` / `import-prowler`	Evidence from AWS Security Hub, Config, Prowler
Classify each KSI	`efterlev agent gap`	Per-KSI status: implemented / partial / not_implemented / not_applicable / evidence_layer_inapplicable
Draft narratives	`efterlev agent document`	Per-KSI attestation narrative with citations
Author procedural attestations	Evidence Manifests under `.efterlev/manifests/*.yml`	Human-signed evidence for KSIs the scanner can't reach (personnel, training, incident response)
Track how close you are	`efterlev readiness`	Heuristic 0–100% scorecard + top blockers
Gate on the RFC-0017 requirements	`efterlev readiness --strict`	Per-KSI pass/fail against the 5 PVA items; exit 2 on any failure
Run the whole pipeline	`efterlev report run`	All of the above in one command

The KSI catalog is the vendored FRMR (60 KSIs across 11 themes), content-addressed and hash-verified on every run.

Honest gap: Efterlev evidences the KSIs reachable from infrastructure-as-code and runtime tool output. Procedural KSIs (personnel security, training, incident-response process) require human-authored Evidence Manifests — the tool scaffolds and validates them but cannot generate the underlying facts. Roughly the AFR / CED / INR themes are procedural by nature.

Stage 2 — 3PAO assessment¶

What happens: You engage a Third Party Assessment Organization (3PAO). They independently validate that your evidence supports your claims.

Who does it: The 3PAO. By design, this is independent of you and of any tool you used.

Where Efterlev fits: 🟡 Partial. Efterlev makes the assessor's job faster by handing them a coherent, traceable artifact instead of a pile of screenshots:

efterlev report inspector produces a single-page HTML view — one row per KSI, the RFC-0017 5-item checklist, evidence citations (file:line), and the draft narrative, all in context. It's built for the assessor to read.
The rfc-mapping.md table lets the 3PAO see exactly which artifact satisfies which RFC requirement without reverse-engineering it.
Every artifact carries a type-level DRAFT marker, so the assessor is never misled into treating a draft as a finished assessment.

Honest gap: Efterlev is not a 3PAO and produces nothing that substitutes for an independent assessment. The assessor's professional judgment is the verdict; the tool only exposes the structure they verify against.

Stage 3 — Submission¶

What happens: You assemble the authorization package and submit it to FedRAMP (and/or the authorizing agency).

Who does it: Your compliance lead, packaging the engineering output + the 3PAO's assessment.

Where Efterlev fits: 🟢 Strong (for the parts it owns):

efterlev submission package bundles the latest of each artifact — FRMR attestation, POA&M (markdown + OSCAL), OSCAL Component-Definition, VDR, consolidated inventory, gap + documentation + inspector HTML, and all Evidence Manifests — into one zip with a README, a machine-readable index.json, and a SHA-256 per artifact.
OSCAL output (POA&M + Component-Definition) validates against three independent gates including the official NIST oscal-cli. This is over-delivery for 20x (OSCAL is a Rev 5 requirement per RFC-0024) but exactly right if you also serve Rev 5 customers.

Honest gap: The submission workflow — uploading to the FedRAMP system, agency correspondence, package-format specifics that FedRAMP may finalize later — is outside Efterlev. Efterlev produces the contents; you submit them.

Stage 4 — Authorization¶

What happens: The authorizing agency reviews your package and, if satisfied, grants the Authorization to Operate (ATO).

Who does it: The agency / authorizing official. Entirely their call.

Where Efterlev fits: ⚪ Out of scope. Efterlev produces no authorization, makes no representation about whether you'll get one, and plays no role in the agency's decision. The DRAFT marker on every artifact is the explicit boundary: a human reviewer (and ultimately an agency) is the only path to "authorized."

Stage 5 — Continuous Monitoring (ConMon)¶

What happens: After authorization, you continuously re-validate that your system still meets the KSIs and you report changes on the cadence RFC-0017 requires (Moderate: machine validation every 3 days, human validation every 3 months).

Who does it: Your engineering + compliance teams, on an ongoing basis.

Where Efterlev fits: 🟢 Strong on the machine cadence, with more planned:

The per-PR scan (bundled pr-compliance-scan.yml GitHub Action) plus on-save efterlev report run --watch already meets RFC-0017's 3-day Moderate machine-validation cadence.
efterlev report diff compares two gap-report snapshots and flags regressed KSIs — usable in CI to block a PR that worsens posture.
The human cadence is met via per-manifest next_review dates on Evidence Manifests.
🔵 Planned: a monthly POA&M delta (efterlev poam delta) that shows what changed between two snapshots — the next ConMon-shaped artifact, folding in the RFC-0016 (Collaborative Continuous Monitoring) streaming concept.

Honest gap: Today's ConMon support is snapshot-and-diff, not a streaming event log. RFC-0016's continuous-monitoring event shape is the next step up; see rfc-mapping.md for the RFC-0016 status.

Stage 6 — Incident response¶

What happens: When a security incident occurs, you follow your documented incident-communication procedures — impact rating, agency notification within the required SLA, status-page updates, and the initial / ongoing / final incident reports (RFC-0031).

Who does it: Your security + operations teams, following a playbook.

Where Efterlev fits: 🟡 Partial. The existence of a documented incident-communication playbook is evidenced via the KSI-AFR-ICP Evidence Manifest. The quantitative, operational requirements (impact-rating scale, the notification SLA, a public status page) are not infrastructure-as-code and are not scanner-able — they're covered by customer-authored manifests and operational policy.

Honest gap: Incident response itself is operational, not a tool output. Efterlev can attest that you have a playbook; it cannot run your incident response.

Where Efterlev is strongest¶

Stage 0  Strategic        🟡  orient + scaffold
Stage 1  Engineering      🟢  ← the core; this is what Efterlev is for
Stage 2  3PAO assessment  🟡  hand the assessor a coherent artifact
Stage 3  Submission       🟢  one-command package for the parts it owns
Stage 4  Authorization    ⚪  agency-only
Stage 5  ConMon           🟢  meets the machine cadence; more planned
Stage 6  Incident         🟡  attest the playbook exists

The honest summary: Efterlev does the most for Stage 1 (engineering readiness) and Stage 3 (submission packaging), helps meaningfully at Stages 2 and 5, and stays deliberately out of the agency-decision and incident-response work that isn't a tool's job.

If you take one thing away: Efterlev gets you from "we have AWS infrastructure" to "we have a reviewer-ready, provenance-tracked draft of our KSI posture" — and it's honest at every step about which parts a human still has to own.