# Boundera Full LLM Context > Full generated index of published Boundera blog posts and resources available through the current content helpers. ## Overview Boundera helps cloud service providers prepare for FedRAMP 20x and Rev 5 by turning infrastructure, repository, document, and vulnerability evidence into authorization-ready workflows. ## Key Tools and Services - [MCP Connector](https://boundera.io/connect): Connect Claude, Cursor, and Codex to Boundera through the Model Context Protocol (MCP). - [Free FedRAMP 20x Gap Assessment](https://boundera.io/fedramp-gap-assessment): Find a likely certification path and class, Marketplace listing gaps, and readiness across all 10 KSI families in about five minutes. - [FedRAMP Consolidated Rules Explorer](https://boundera.io/consolidated-rules): Filter current 2026 requirements by certification type, path, service class, party, and force level, then export the scoped results. - [FedRAMP Automation Platform](https://boundera.io/fedramp-automation): Automate KSI evidence, control validation, SSP and POA&M workflows, OSCAL output, reporting, and continuous monitoring. - [FedRAMP Rev 5 Deadlines & Consolidated Rules](https://boundera.io/rev5): Prepare for FedRAMP Rev 5 deadlines with Boundera: manage VDR and VER workflows, maintain your SDR and certification package, and share evidence. - [FedRAMP Rev 5 Vulnerability Management: VDR & VER](https://boundera.io/rev5/vulnerabilities): Manage FedRAMP Rev 5 vulnerabilities with Boundera: evaluate findings in batches, track response plans and evidence, and prepare connected VER reports. - [FedRAMP Rev 5 Certification Package: SDR & CPO](https://boundera.io/rev5/certification-package): Maintain your FedRAMP Rev 5 certification package with Boundera. Reuse SSP work, review evidence gaps, and export SDR and CPO records in JSON and HTML. - [FedRAMP Rev 5 Evidence Sharing & Assessor Review](https://boundera.io/rev5/evidence-sharing): Share FedRAMP Rev 5 certification records through a controlled Trust Center. Connect evidence, assessor requests, package versions, and review history. - [FedRAMP Advisors & Assessors](https://boundera.io/fedramp-advisory-services): Contact Boundera for an introduction to the advisors and independent assessors we work with. Boundera provides compliance automation software and does not offer advisory services. - [FedRAMP Marketplace Listing Guide](https://boundera.io/fedramp-marketplace-listing): Understand what an Initial Implementation Phase Marketplace listing requires under the Consolidated Rules for 2026 — no assessment, no independent assessor, and mandatory before applying for a FedRAMP Certification. - [SDR Redactor](https://tools.boundera.io/sdr-redactor/): Redact a FedRAMP Security Decision Record so it can be shared: statuses, FedRAMP identifiers, dates, and counts stay, while narrative text, links, and resource, account, and people identifiers are replaced. Free, open source, and runs entirely in the reader's browser. - [Boundera FedRAMP Trust Center](https://boundera.io/tc/fedramp-trust-center): View Boundera's public FedRAMP 20x certification scope, KSI results, documents, and machine-readable authorization data. ## Canonical Hubs - [Homepage](https://boundera.io/) - [FedRAMP 20x](https://boundera.io/fedramp-20x) - [FedRAMP 20x KSI Atlas](https://boundera.io/fedramp-20x/ksi) - [FedRAMP 20x Rules Atlas](https://boundera.io/fedramp-20x/rules) - [FedRAMP 20x Glossary](https://boundera.io/fedramp-20x/glossary) - [Blog](https://boundera.io/blog) - [FedRAMP 20x Blog](https://boundera.io/blog/20x) - [Rev 5 Blog](https://boundera.io/blog/rev5) - [Resources](https://boundera.io/resources) - [FedRAMP 20x Resources](https://boundera.io/resources/20x) - [Rev 5 Resources](https://boundera.io/resources/rev5) - [Request Demo](https://boundera.io/request-demo) ## All Published Blog Posts ### FedRAMP 20x: Test Trust Center Programmatic Access Before Buying - URL: https://boundera.io/blog/20x/fedramp-20x-trust-center-programmatic-access-test - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-12T14:07:20.962Z - Updated: 2026-10-12T14:12:38Z - Reading time: 6 minutes - Main question: How should a Class B or C provider test trust center programmatic access before buying? - TL;DR: Ask the vendor to demonstrate documented retrieval from your own client using an approved identity and an agreed inventory. Test structured records and human-readable materials, repeat access, check a controlled update, and record gaps as purchasing acceptance items. - Excerpt: Evaluate a trust center with a practical retrieval demonstration covering structured records, human-readable materials, repeat access, and version checks. Before buying a trust center for your Class B or C offering, ask the vendor to demonstrate retrieval from your own test client. Start with an approved identity and a written inventory, then retrieve structured records and human-readable documents using the supplied instructions. Repeat the exercise after a controlled update. Use this FedRAMP trust center programmatic access test as a purchasing exercise. The steps, sample records, and acceptance criteria below are our implementation advice. Treat the result as evidence for your buying decision; do not treat a successful demonstration as a certification decision or a complete review of every applicable rule. ## Establish the rule baseline and adoption dates The official [Class B](https://github.com/FedRAMP/2026-markdown/blob/HEAD/reference/20x/b/certification-data-sharing.md) and [Class C Certification Data Sharing rules](https://github.com/FedRAMP/2026-markdown/blob/HEAD/reference/20x/c/certification-data-sharing.md) include the following trust-center provisions: - **CDS-TRC-PAC uses MUST:** documented programmatic access must cover all FedRAMP Certification Data, including human-readable materials. - **CDS-TRC-USH uses MUST:** sharing with all necessary parties must continue without interruption. - **CDS-TRC-HMR uses SHOULD:** the data should be available to view and download in both human-readable and machine-readable formats. - **CDS-TRC-SSM uses SHOULD:** features should encourage necessary parties to provision and manage access directly for their users and services. Under FedRAMP's [SHOULD definition](https://github.com/FedRAMP/2026-markdown/blob/HEAD/definitions.md#should), valid reasons to depart from a rule can exist, but its full implications must be understood and carefully weighed. Parties must explain their decisions about handling such rules in their security documentation. The CDS pages list July 4, 2026 for optional adoption and obtaining initial certification. They list January 1, 2027 for maintaining ongoing certification, with the grace period ending on the first FedRAMP independent assessment started after that date. These are published Consolidated Rules for 2026 provisions; the purchasing exercise in this article is our suggested way to evaluate an implementation. Record the offering's certification stage and applicable adoption date in the buying brief. Keep a separate column for your commercial acceptance criteria so a vendor can distinguish a rule obligation from a requested feature. ## Define the demonstration scope Ask your security and engineering leads to prepare a data inventory before the sales call. For each item, name the offering, expected version, format, approved audience, and documented retrieval method. Include examples from your actual package structure, with suitable test content where real material cannot be shared. For a manageable first demonstration, choose one structured package record, one human-readable policy, and one human-readable report. Then ask the vendor to account for the remaining inventory. Sampling is a way to organize your evaluation, not a reason to leave items unexamined before acceptance. Use a worksheet with these columns: | Item | Expected result | Observed result | Gap and owner | | --- | --- | --- | --- | | Structured record | Retrieve and parse the expected version | Record the returned identifier and version | Assign any mapping repair | | Human-readable policy | Retrieve and open the expected document | Record the title and revision | Assign any document access repair | | Human-readable report | Retrieve the intended offering's report | Compare with the inventory entry | Assign any scope mismatch | | Repeat access | Retrieve again using documented authentication | Record any added approval step | Assign any access workflow repair | Set these expectations with the vendor before running the test. Ask for an explanation whenever an item uses a different retrieval mechanism, uses a separate account, or depends on a manual export. ## Run the retrieval from a buyer-controlled client Have a member of your team follow the documentation without relying on a vendor administrator's active session. Use an identity approved for the agreed test material. Ask the vendor to identify the supported authentication method, permission setup, error responses, and any restrictions that could affect your expected retrieval pattern. Retrieve the structured record, parse it, and compare its offering and version with the inventory. Next, retrieve each human-readable sample through the documented programmatic route and open the returned material. A response code alone is a weak acceptance criterion: inspect whether you received the intended document, an error page, or a link that still involves an unexplained manual step. Keep a sanitized record of the documentation version, request time, item identifier, and observed result. Exclude access credentials from the worksheet. When the vendor has to intervene, record what changed and rerun the affected step from your client. For the wider operating process behind these items, use our [authorization data sharing workflow](/blog/20x/fedramp-20x-authorization-data-sharing-workflow). Keep this buying exercise focused on whether your team can retrieve and use the agreed material. ## Repeat authorized access and test a controlled update The note to CDS-TRC-USH explains that parties should not need fresh manual approval each time they access certification data or face a complicated process. It identifies on-demand just-in-time provisioning as the preferred approach. For your demonstration, repeat retrieval after signing out or renewing the test client's authentication through the documented process. Record whether the same authorized party encounters another discretionary approval queue. Ask the vendor to explain how necessary parties retain access as credentials and sessions change. Then change one test document and one structured record under your agreed update procedure. Retrieve both again, compare versions, and record how your client identifies the intended update. Treat this as an engineering acceptance test; choose the update interval to reflect your proposed operating process. For permission history and access activity, continue with the separate [agency access records workflow](/blog/20x/fedramp-20x-trust-center-agency-access-records). That topic deserves its own review alongside the retrieval demonstration. ## Make the purchasing decision from observed gaps Classify each observed gap as missing documentation, missing material, incorrect offering or version, access friction, or an unresolved integration dependency. Name a repair owner and require a repeat demonstration of the corrected behavior before closing that item in your evaluation. For example, suppose the structured package record downloads successfully, but the policy document can only be obtained after a new email exchange. Mark the policy retrieval as unresolved and ask the vendor to demonstrate its documented programmatic route. Do not let the successful structured record stand in for the missing document test. Finish with a short decision record: what you tested, what you did not test, who observed the results, and which gaps remain. Use that record to negotiate implementation work and acceptance milestones. Revisit the complete applicable rules with your assessment team before relying on the selected platform for your certification workflow. ## Frequently asked questions ### What should a trust center buying demonstration include? We recommend an approved test identity, an agreed data inventory, retrieval of structured and human-readable samples, repeat authorized access, and a controlled version update. Document the results and assign every unresolved gap an owner. ### What does CDS-TRC-PAC say about human-readable materials? CDS-TRC-PAC requires documented programmatic access to all FedRAMP Certification Data, including human-readable materials. Include those materials explicitly in your purchasing demonstration. ### How should we score a feature that is still on the roadmap? Record it as an unresolved delivery dependency. Ask for a committed implementation milestone and a repeatable acceptance demonstration before treating it as available for your deployment. ### FedRAMP 20x: Handle Denied Agency Package Access Requests - URL: https://boundera.io/blog/20x/fedramp-20x-agency-access-denial-notification - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:43:17.194403+00:00 - Updated: 2026-10-10T23:46:24Z - Reading time: 3 minutes - Main question: When does a Class B/C provider need to notify FedRAMP about denied agency access? - TL;DR: For providers using a FedRAMP-compatible trust center instead of USDA Connect, CDS-UTC-AAD requires notification within five business days of denying an agency request for Certification Data. Record the decision and notify through the official form while preserving broader sharing obligations. - Excerpt: Handle denied agency package-access requests for Class B/C providers using a compatible trust center, preserving the five-business-day notification trigger. When an agency's request for package access is denied, the decision needs a clear owner and a reliable notification path. For Class B and C providers using a FedRAMP-compatible trust center instead of USDA Connect, FedRAMP 20x agency access denial notification has a specific trigger and a five-business-day timeframe. ## Confirm that the trust-center subset applies The [Using a Trust Center subset](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing/#using-a-trust-center) applies to providers using a FedRAMP-compatible trust center instead of USDA Connect. It expressly does not apply to providers using USDA Connect. Check that applicability before building an operating procedure around CDS-UTC-AAD. Under CDS-UTC-AAD, providers MUST notify FedRAMP within five business days of denying an agency access request for Certification Data. The rule directs providers to the official [[CSP] Agency Access Denial form](https://help.fedramp.gov/hc/en-us/requests/new?ticket_form_id=51829826617243). Keep the triggering decision clear. A failed login, expired invitation or temporary retrieval error does not by itself establish that an agency access request was denied. Investigate what happened and identify the actual request and decision before classifying an event. Do not let that investigation become an excuse to lose track of an actual denial and its notification window. ## Record the decision while its context is available As an operating practice, record the requesting agency, the offering and FedRAMP identifier, the requested materials, the decision time, the rationale and the responsible owner. Keep the original request and decision evidence linked to that record. These fields are an internal workflow suggestion, not a new FedRAMP form specification. Assign a notification owner when the denial is recorded. Track the five-business-day window from the denial and retain the submission evidence. A second owner can cover absence or a handoff, so the notification does not depend on one person's memory. For example, a support ticket may start as a broken-link complaint and later reach a formal access decision. Preserve both events and their timestamps. Treat technical troubleshooting and the access decision as distinguishable work, so the team can explain which event triggered the notification. ## Preserve the broader access obligations CDS-UTC-AGA says providers SHOULD supply agencies access to the Certification Package upon request. Separately, CDS-TRC-USH requires trust centers to share Certification Data with all necessary parties without interruption. The denial-notification rule does not grant permission to withhold data or create a list of approved reasons for denial. Review an access decision against the applicable sharing obligations. Use the [responsible package-sharing guidance](/blog/20x/fedramp-20x-package-sharing-sensitive-details) when deciding how to present sensitive details without obscuring risk information. Our [agency package-handoff guide](/blog/20x/fedramp-20x-agency-onboarding-package-handoff) addresses the earlier delivery workflow. The five-business-day notification is a report after a denial; the rule does not describe an advance-approval process. Avoid inventing an internal sign-off chain that makes timely notification depend on waiting for unrelated approvals. ## Close the notification loop Keep the submission reference with the decision record and assign any follow-up correspondence to an owner. If access is later supplied, preserve that later event as part of the history. The operational goal is a reconstructable sequence from request to decision, notification and subsequent action. The CDS adoption page lists optional and initial certification adoption from July 4, 2026, ongoing adoption on January 1, 2027, and grace until the first independent assessment started after January 1, 2027. These are adoption milestones; the five-business-day period is tied to a denied request. Test the workflow with a sample decision and confirm that the owner can find the official form and the supporting record. ### FedRAMP 20x: Do You Need a Separate Government Deployment? - URL: https://boundera.io/blog/20x/fedramp-20x-separate-government-deployment - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:44:13.155470+00:00 - Updated: 2026-10-10T23:46:01Z - Reading time: 3 minutes - Main question: Do Class B/C teams pursuing FedRAMP 20x need a separate government deployment? - TL;DR: M-24-15 directs FedRAMP away from incentivizing or requiring separate federal offerings, but does not approve a particular architecture. Compare shared and dedicated designs using actual federal-data handling, security impact, agency needs and operating responsibility. - Excerpt: Compare shared and dedicated deployment designs for Class B/C using the shared-infrastructure policy, actual assessment scope and agency needs. Creating a second deployment can mean a second release path, another operating environment and more security work to maintain. Before making that investment, Class B and C engineering leaders evaluating a FedRAMP 20x separate government deployment should examine the actual architecture and agency needs. A government-only environment is not the starting assumption of the shared-infrastructure policy. ## Read the policy direction in context [OMB M-24-15's vision for FedRAMP](https://github.com/FedRAMP/2026/blob/HEAD/content/authority/m-24-15/vision.md) says the program should avoid creating incentives or requirements that push commercial providers into dedicated federal offerings. It describes benefits from the investment, security maintenance and development that providers put into their core commercial products. That is policy direction for the program, not approval of a specific shared architecture. It neither certifies a commercial deployment nor instructs every provider to close government-specific infrastructure. Treat it as a reason to evaluate the existing commercial architecture seriously, rather than treating duplication as automatic. The memorandum's [authorization-process section](https://github.com/FedRAMP/2026/blob/HEAD/content/authority/m-24-15/process.md) preserves agency authorizing officials' decisions about acceptable risk for their agency. It also explains that FedRAMP does not replace other applicable legal, Executive Order, regulatory or OMB requirements. Deployment planning still needs the relevant agency and compliance context. ## Test the real assessment scope For the Class B/C scope considered here, [Minimum Assessment Scope](https://www.fedramp.gov/2026/providers/20x/rules/minimum-assessment-scope) rule MAS-CSO-IIR requires identifying the resources likely to handle federal customer data or likely to affect its confidentiality, integrity or availability. MAS-CSO-FLO requires identifying, documenting and explaining information flows and security categories for the offering's information resources or resource sets. A separate account name alone cannot answer those questions. Examine the data paths and operational dependencies in both candidate designs. Shared identity services, deployment systems and administrative tooling are useful places to investigate, based on their actual handling of or impact on federal customer data. Apply the rule's scope tests and exclusions rather than automatically including or excluding a category by label. For detailed follow-up, use the [metadata assessment-scope guide](/blog/20x/fedramp-20x-metadata-assessment-scope) and [third-party impact records guide](/blog/20x/fedramp-20x-third-party-resource-impact-records). Those operating questions remain relevant even when production workloads sit in a dedicated environment. ## Compare two concrete operating designs As an engineering decision aid, compare the current commercial deployment with a specific dedicated alternative. Record how each design handles federal data, grants privileged access, uses shared dependencies and distributes operating responsibility. Include the work needed to produce and maintain assurance evidence for each design. For example, a dedicated production account may still rely on the commercial deployment pipeline and identity provider. The comparison should make those dependencies visible and explain the resulting security controls. Conversely, a shared production design may have requirements that need additional work before it can support the intended agency use. Ask who will maintain each release path, investigate incidents and keep the evidence current. This comparison is editorial engineering advice, not an official FedRAMP decision-record template. It should help the team understand the cost and security consequences of its options without promising certification for either one. ## Make the decision reviewable Save the selected design, the assumptions behind it, unresolved agency needs and the events that would cause the team to revisit the choice. Connect the decision to the [evidence-readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) so architecture planning leads to concrete assessment preparation. The current MAS page lists optional and initial adoption from July 4, 2026, ongoing adoption on January 1, 2027, and grace until the first independent assessment started after January 1, 2027. Those are MAS adoption milestones. The shared-infrastructure direction comes from the 2024 memorandum, not a new 2026 requirement to reorganize deployments. Start with an evidence-based comparison of the offering you have and the alternative you would actually operate. ### FedRAMP 20x: Handle FedRAMP-Issued Certification Reports - URL: https://boundera.io/blog/20x/fedramp-20x-certification-report-intake - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:40:44.259942+00:00 - Updated: 2026-10-10T23:43:28Z - Reading time: 3 minutes - Main question: How should Class C teams handle FedRAMP 20x certification report intake? - TL;DR: CDS-CSO-FRC requires including FedRAMP-issued Certification Reports without inappropriate modifications and making them available within two weeks of receipt. Track the received files, offering, owner and retrieval checks, keeping the report distinct from provider and assessor materials. - Excerpt: Handle FedRAMP-issued reports for Class C offerings, preserve the received material and track the two-week availability requirement from receipt. Receiving a report from FedRAMP creates an intake task: put the right material into the right offering's Certification Data, preserve its meaning and make it accessible on time. For Class C teams, a FedRAMP 20x certification report intake workflow helps prevent an important document from remaining in an individual's inbox. ## Identify the issuer and the material The [FedRAMP Certification Report definition](https://www.fedramp.gov/2026/definitions/#fedramp-certification-report) describes a report produced by FedRAMP that documents the results of a certification assessment. It is typically produced after the initial Program Certification assessment and updated as necessary during ongoing certification. FedRAMP may also produce one at any time for an offering during ongoing certification activities, including corrective action. The [Certification Data Sharing rules](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing) explain that FedRAMP provides these reports for Program-path offerings during initial and ongoing certification and may provide them for Agency-path offerings. Do not assume every Agency-path offering has received one. Keep this material distinct from a provider's own ongoing report and an independent assessor's findings. Its defining characteristic is that FedRAMP produced it. Our [assessor-findings guide](/blog/20x/fedramp-20x-preserving-assessor-findings) covers the separate handling of assessment findings. ## Start the intake timer at receipt CDS-CSO-FRC requires providers to include FedRAMP Certification Reports with their Certification Data without inappropriate modifications. It also requires making them available within two weeks of receiving the materials from FedRAMP. Record the receipt time and associate it with the offering, the received files and the person responsible for making them available. These are practical intake fields, not an additional official report template. A clear owner prevents the timer from disappearing during handoffs between compliance, engineering and trust-center administration. Use receipt from FedRAMP as the trigger described by the rule. Do not replace it with a recurring two-week publishing schedule or casually start the timer from a date printed inside the document. If receipt details are unclear, resolve that uncertainty promptly and preserve the supporting correspondence. ## Preserve the report while making it usable Keep the received report intact in the intake record. Check that the offering identifier and report version match the destination package before linking it into Certification Data. If the report appears to contain an error or is difficult to render, route the issue to the responsible contact and preserve the original while it is resolved. Separate navigation aids from the report itself. An index entry or internal summary can help a reader find the relevant material, but should remain visibly distinct from FedRAMP's report. That separation makes it easier to avoid inappropriate modifications and to see which statements came from the issuing organization. For trust-center delivery, CDS-TRC-PAC requires documented programmatic access to all Certification Data, including human-readable materials. A report can therefore need a retrievable file path or documented retrieval method; this does not say to rewrite its contents into JSON. Test both an authorized person's retrieval and the documented programmatic method before marking intake complete. ## Close intake with evidence of availability As an operating practice, save the availability time, location and retrieval-check result alongside the receipt record. Connect later report versions to the [package-history record](/blog/20x/fedramp-20x-package-history-report-snapshots) so readers can understand what changed without confusing versions. The CDS adoption framework lists optional and initial certification adoption from July 4, 2026, ongoing adoption on January 1, 2027, and grace until the first independent assessment started after January 1, 2027. Keep that framework separate from the two-week receipt-to-availability requirement. A useful final check is simple: can the intended reader retrieve the exact report that the intake record says was received? ### FedRAMP 20x: Reconcile Agency Access Records in Your Trust Center - URL: https://boundera.io/blog/20x/fedramp-20x-trust-center-agency-access-records - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:41:04.222079+00:00 - Updated: 2026-10-10T23:43:02Z - Reading time: 3 minutes - Main question: How should Class B/C trust centers reconcile FedRAMP 20x agency access records? - TL;DR: CDS requires an inventory and history of agency users or systems with access, available to FedRAMP on request. It separately requires access logging and at least six months of access summaries. Reconcile permission history with activity while preserving request-specific scope. - Excerpt: Reconcile Class B/C trust-center permission history and access activity, with the right six-month summary retention and request-specific retrieval. An agency account can remain on a permissions list without ever opening a package. Another account may appear in access logs after its permissions have changed. For Class B and C trust-center teams, useful FedRAMP 20x agency access records explain both who could access Certification Data and what access actually occurred. ## Keep permissions and activity distinguishable The [Certification Data Sharing rules](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing) contain two related requirements. CDS-TRC-AAI says trust centers MUST maintain an inventory and history of federal agency users or systems with access to Certification Data. That information MUST be available to FedRAMP upon request. CDS-TRC-ACL says trust centers MUST log access to Certification Data and store summaries of access for at least six months. Information about specific parties SHOULD be available upon request by those parties. An access inventory answers a permission question. Activity logs answer an event question. Use the two together, while preserving the different request audiences and rule strengths. The six-month minimum expressly applies to access summaries; it should not be rewritten as a six-month raw-event retention requirement or assumed to define the inventory's entire retention policy. ## Make identity changes explainable As an implementation practice, connect each agency user or system to an identifiable agency, its access scope and its permission changes. Include machine identities in that design: the inventory requirement expressly covers users or systems. Keep administrative display names separate from durable identifiers so a renamed account remains traceable. For example, an agency might replace a service account used to retrieve package materials. A useful history connects the old and new identities to the appropriate permissions and change times. Preserve enough context to explain the transition without treating them as one indistinguishable account. When access is revoked, record the change instead of silently removing all evidence that access existed. This is an engineering recommendation for maintaining understandable history, not a prescribed retention period or an official account-deletion procedure. Our [trust-center agency-scope guide](/blog/20x/fedramp-20x-trust-center-agency-scope) explains how agency-use scope differs from the provider's dependency analysis. ## Reconcile records before a request arrives Compare a sample of permission changes against actual access events. Look for events whose identity cannot be matched, active permissions missing from the inventory, and summaries that omit retrieval activity. Assign an owner to explain discrepancies and record the outcome of the investigation. Test two retrieval scenarios. First, assemble the inventory and history for a FedRAMP request. Second, assemble access information pertaining to a particular requesting party. Use scope checks so the second export does not casually include another party's activity. The rules identify these request audiences; they do not call for public disclosure of agency-access records. Choose a reconciliation frequency that fits the operating environment and record who owns it. AAI and ACL do not specify a universal reconciliation interval. Keep this maintenance plan separate from the required six-month minimum for stored access summaries and from [package-history management](/blog/20x/fedramp-20x-package-history-report-snapshots). ## Track adoption and operating ownership The CDS page lists optional adoption and initial certification adoption from July 4, 2026, ongoing adoption on January 1, 2027, and grace until the first independent assessment started after January 1, 2027. Those adoption dates are distinct from how long access summaries are retained. Give one owner responsibility for producing coherent records across identity management and trust-center logging. A practical first check is to select one agency user and one system account, trace their permission history, and retrieve the corresponding access summary. That small exercise can reveal whether a future request will be answerable. ### FedRAMP 20x: Keep the Vulnerability Evaluation Queue Moving - URL: https://boundera.io/blog/20x/fedramp-20x-vulnerability-evaluation-queue - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:38:52.773441+00:00 - Updated: 2026-10-10T23:41:15Z - Reading time: 3 minutes - Main question: How should Class B/C teams manage the FedRAMP 20x vulnerability evaluation queue? - TL;DR: VER recommends evaluating all vulnerabilities within seven days of detection for Class B and five for Class C. Track that target alongside required exploitability, reachability and likely agency-impact evaluations, and keep evaluation age distinct from treatment status. - Excerpt: Manage Class B/C vulnerability evaluations using detection age, missing evidence and completed decisions, while preserving the recommended timing windows. A vulnerability queue can look busy while important evaluations remain unfinished. For Class B and C teams, managing the FedRAMP 20x vulnerability evaluation queue means making detection time, missing evidence and completed decisions visible. Assigning a ticket is a useful start; it does not explain the finding's exploitability, reachability or likely agency impact. ## Track the recommended evaluation window The current [Vulnerability Evaluation and Reporting rules](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting) separate evaluation timing from the evaluation itself. VER-TFR-EVU says Class B providers SHOULD evaluate all vulnerabilities within seven days of detection. For Class C, the recommendation is five days. Keep SHOULD visible when turning that recommendation into an operating target. It is not a universal mandatory five-day deadline, and it is not a reason to delay urgent response. Evaluation timing also differs from mitigation and remediation timing. Avoid using one due-date column to represent every kind of work. As an operating practice, calculate queue age from the detection timestamp and show the applicable class target beside it. Preserve that provenance when a finding changes owner, is grouped with related findings or is moved between systems. A freshly created ticket should not obscure an older detection event. ## Define what completes the evaluation VER-EVA-ELX requires evaluating detected vulnerabilities in the context of the offering to determine likely exploitability. VER-EVA-EIR requires evaluating internet reachability. VER-EVA-EPA requires estimating likely potential agency impact using the current PAIN levels, N0 through N5. A useful queue therefore identifies what is still missing from each decision. A scan result may need resource context, a payload path, evidence about compensating conditions or a clearer explanation of effects on agency customers. Give each unresolved question an owner and a next action. That workflow is editorial implementation advice, not an additional FedRAMP queue schema. Consider a finding on a resource that appears inaccessible from the internet. Route the reachability question to someone who can examine the actual path. Route the impact question to someone who understands the affected agency functions. Use the [payload-tracing workflow](/blog/20x/fedramp-20x-internet-reachability-payload-tracing) and [PAIN rating guidance](/blog/20x/fedramp-20x-pain-rating-customer-effects) for those separate decisions. ## Carry the result into reporting VER-RPT-VDT requires information, where applicable, about detected vulnerabilities unless they are accepted vulnerabilities. Its fields include an internal identifier, detection time and source, completed evaluation time, reachability, exploitability, historical and current PAIN ratings, and response timing information. The rule contains the full list; a queue view can expose a practical subset without replacing the required report. Record when the evaluation actually finishes and connect the result to the supporting evidence. Keep accepted findings connected to their [accepted-vulnerability records](/blog/20x/fedramp-20x-accepted-vulnerability-records), which have a separate reporting provision. An aging evaluation ticket is not automatically an officially defined overdue vulnerability. The [FedRAMP definition](https://www.fedramp.gov/2026/definitions/#overdue-vulnerability) concerns a vulnerability the provider intends to fully mitigate or remediate but has not, or will not, within the recommended or required timeframes. Keep an internal evaluation-age alert distinct from that treatment status. ## Review the oldest unresolved decisions Use a short operating review to identify findings approaching the class target, explain the missing evidence and assign a concrete next step. Sample completed evaluations as well: closing tickets quickly is less useful when decisions cannot be reconstructed. The VER adoption dates are optional adoption from July 4, 2026, initial and ongoing certification adoption on December 7, 2026, and grace through March 7, 2027. Track those dates separately from each finding's evaluation window. Start by examining the oldest open finding and confirming that its age, owner and remaining decision are clear. ### FedRAMP 20x: Build a Historical Vulnerability Activity Feed - URL: https://boundera.io/blog/20x/fedramp-20x-historical-vulnerability-activity-feed - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:37:38.727878+00:00 - Updated: 2026-10-10T23:40:43Z - Reading time: 3 minutes - Main question: How should Class B/C teams build a FedRAMP 20x historical vulnerability activity feed? - TL;DR: VER distinguishes mandatory persistent reporting and monthly human-readable reports from recommended JSON history retrieval. History updates are recommended at least monthly for Class B and every 14 days for Class C. Reconcile event coverage across the feed and reports. - Excerpt: Build a Class B/C vulnerability history feed while keeping persistent reporting, human-readable reports and recommended JSON update schedules distinct. A reviewer who sees only today's vulnerability totals cannot reconstruct what changed. For 20x Class B and C teams, a FedRAMP 20x historical vulnerability activity feed should connect findings, evaluations and response activity across reporting periods. Start with the reporting obligations, then design the retrieval mechanism around them. ## Separate the three reporting expectations The current [Vulnerability Evaluation and Reporting rules](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting) distinguish persistent reporting, human-readable reports and machine-readable history. Under VER-RPT-PER, providers MUST report detection and response activity, including persistent verification and validation, to all necessary parties persistently. Each report summarizes ALL activity since the previous report. These reports are Certification Data and are subject to Certification Data Sharing rules. VER-TFR-MHR separately requires a human-readable report in a consistent format at least monthly. VER-TFR-MRH uses SHOULD for making all recent historical detection and response activity available in JSON for automated retrieval by all necessary parties. Its update recommendation is at least monthly for Class B and at least every 14 days for Class C. An API service is an example in the rule; a similar retrieval mechanism can serve the recommendation. Do not collapse those statements into a single mandatory API schedule. Keep the mandatory reporting requirements and the recommended history updates visible in the implementation plan. ## Preserve changes, not just the latest row As an engineering practice, use stable finding identifiers and retain enough event context to explain changes between reports. A useful event record connects a finding to its resource, detection time, evaluation, response action and the time of that change. These are design suggestions for a usable feed, rather than a prescribed event schema. For example, a finding could move through evaluation, a revised impact rating and mitigation during one reporting period. Exporting only the last state would make the intervening work harder to review. Keep the sequence available alongside the current state, and use the [PAIN rating guidance](/blog/20x/fedramp-20x-pain-rating-customer-effects) when explaining the impact assessment. Keep original timestamps separate from export timestamps. Treat generating a new export as a reporting operation; preserve the underlying response timeline. For accepted findings, connect the history to the [accepted-vulnerability record](/blog/20x/fedramp-20x-accepted-vulnerability-records) instead of dropping the finding from the history. ## Reconcile retrieval with the human report Build a reporting check that compares the period covered by the human-readable report with the events exposed through automated retrieval. Investigate missing events, duplicate identifiers and mismatched totals before release. A report with accurate totals can still be difficult to audit if the underlying events cannot be located. Agency-specific views can help readers navigate, but keep the required reporting coverage intact. An interface filter should not silently become the rule for which activity enters the reporting record. Authenticate retrieval and test access for the necessary parties; the rule describes those parties, rather than a public vulnerability feed. The history recommendation does not specify a universal retention duration. Set an explicit retention design using the applicable requirements and operating needs, and document it separately from the monthly or 14-day update schedule. Our [JSON validation workflow](/blog/20x/fedramp-20x-json-schema-validation-workflow) covers useful checks before consumers ingest an export. ## Put the dates beside the implementation work The current VER page lists optional adoption from July 4, 2026, initial and ongoing certification adoption dates of December 7, 2026, and grace through March 7, 2027. Track that adoption framework separately from the recurring reporting frequencies. For the implementation owner, the next step is concrete: compare one completed reporting period across the event store, JSON retrieval and human report. Use the discrepancies to repair coverage and traceability before expanding the feed. ### FedRAMP 20x: Maintain a Policy and Procedure Reference Index - URL: https://boundera.io/blog/20x/fedramp-20x-policy-procedure-reference-index - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:34:32.664217+00:00 - Updated: 2026-10-10T23:38:50Z - Reading time: 3 minutes - Main question: What belongs in a Class B or C policy and procedure reference, and how can it stay current? - TL;DR: CDS-CSO-IRP requires relevant policies and procedures plus a human-readable and machine-readable reference with seven information categories. Keep entries linked to controlled sources and refresh them with document changes. CDS-CSO-CBF requires automated consistency between the two formats. - Excerpt: Maintain Class B and C policy references with all seven information categories, linked source documents and consistent human and machine views. A FedRAMP 20x policy procedure reference index helps readers find the right document and understand its current version. For Class B and C package owners, keep the reference connected to the actual policies and procedures being supplied. The operating problem is familiar: a policy changes, but the package still points to an old file, summary or version. Treat the reference as maintained information with a clear source and owner. ## Supply the policies and their reference information CDS-CSO-IRP requires all relevant policies and procedures in the Certification Data, including a human-readable and machine-readable reference explaining at least seven categories about each included document. [FedRAMP Certification Data Sharing](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing) Those categories are: 1. The policy or procedure name. 2. The file, document, webpage or equivalent name. 3. A brief summary. 4. The document's word count. 5. Its current version. 6. The date of its last update. 7. Related FedRAMP Practices, if applicable. The requirement includes supplying the relevant policies and procedures themselves. An index alone does not replace that part of the rule. Keep the reference useful by connecting it to the controlled document rather than treating it as a standalone list of titles. ## Refresh the reference when the document changes As an implementation practice, use the document's revision process to refresh its reference entry. Recheck the summary, word count, version, update date and related practices after substantive edits. Confirm the displayed file or page name still leads to the intended material. For example, a procedure may be split into two documents. Review whether the old entry should now lead to two current references and whether each new summary explains the resulting scope. Preserve a way to understand the change internally without leaving the reader to guess which document applies. Assign an owner for each reference or document family. This is an editorial operating suggestion, not a fixed FedRAMP refresh interval or prescribed index schema. ## Keep the human and machine views consistent CDS-CSO-CBF requires automation to ensure consistency between human-readable and machine-readable information when Certification Data is provided in both formats. [FedRAMP CDS-CSO-CBF](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing) One implementation option is to maintain a single reference record and generate both views from it. Another is an automated comparison between maintained representations. Test that a version or word-count change appears consistently in the output your readers and tools consume. The [JSON validation workflow](/blog/20x/fedramp-20x-json-schema-validation-workflow) can support validation where your implementation uses JSON. Keep the reference-format obligation distinct from the format of every underlying policy document. ## Test access and keep history understandable As a practical retrieval exercise, choose several entries and open their source documents through the intended access path. Check that the current reference points to current content and that the reader can distinguish it from retained historical material. The [package history guide](/blog/20x/fedramp-20x-package-history-report-snapshots) addresses report-aligned snapshots. Use the [sensitive-data guide](/blog/20x/fedramp-20x-package-sharing-sensitive-details) when reviewing what information is shared with recipients. The CDS page lists July 4, 2026 for initial certification and January 1, 2027 for ongoing certification, with grace ending on the first independent assessment started after January 1, 2027. Keep the applicable Class B or C context with your implementation. A useful index lets a reader identify the document, understand its purpose and retrieve the stated version, while automation keeps the two reference views aligned. ### FedRAMP 20x: Document Third-Party Resource Impact - URL: https://boundera.io/blog/20x/fedramp-20x-third-party-resource-impact-records - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:33:13.026068+00:00 - Updated: 2026-10-10T23:37:05Z - Reading time: 3 minutes - Main question: What should Class B and C providers document about applicable third-party resource impact? - TL;DR: Start with FRD-TPR and the MAS-CSO-IIR condition. MAS-CSO-TPR calls for usage and configuration, justification, mitigation measures and compensating controls for applicable resources. Connect that information to the human-readable and JSON package overview and the evidence of actual use. - Excerpt: For Class B and C, apply the scope condition and document applicable third-party resource use, justification, mitigation measures and compensating controls. FedRAMP 20x third party resource documentation should explain how an applicable resource can affect federal customer data and what the provider does about that impact. For Class B and C package owners, start with the resource's role and the scope condition, then assemble the required information. A purchasing-system vendor list is useful context, but it is not the same analysis. The FedRAMP definition concerns the information resource's relationship to the offering's Minimum Assessment Scope. ## Apply the definition and the scope condition FRD-TPR defines a third-party information resource as any information resource not entirely included in the Minimum Assessment Scope for the offering obtaining certification. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/#third-party-information-resource) MAS-CSO-TPR requires providers to address potential impact from third-party resources used by the offering ONLY IF MAS-CSO-IIR applies. IIR's test concerns resources likely to handle federal customer data or likely to affect its confidentiality, integrity or availability in the offering. Preserve that conditional test instead of applying the requirement to every purchased vendor automatically. [FedRAMP Minimum Assessment Scope](https://www.fedramp.gov/2026/providers/20x/rules/minimum-assessment-scope) For your internal analysis, connect the resource to the relevant data flow, dependency or operational capability. Explain why the condition applies, with evidence another reviewer can follow. ## Document the four required categories For each applicable resource, MAS-CSO-TPR specifies four information categories: general usage and configuration; an explanation or justification for use; mitigation measures in place to reduce potential impact to federal customer data; and compensating controls in place to reduce that potential impact. [FedRAMP MAS-CSO-TPR](https://www.fedramp.gov/2026/providers/20x/rules/minimum-assessment-scope) As an editorial working structure, place those categories beside the resource identity and its relationship to the offering. Link the description to architecture and configuration evidence where useful. Describe measures actually in place rather than writing a hypothetical control as if it already operates. For example, an explanation can distinguish why the resource is used from how a specific safeguard limits its potential impact. Those are different questions. A generic statement that the vendor is trusted does not help an engineer understand either the configuration or the safeguard. ## Connect the record to the package overview CPO-CSO-OVR requires the Certification Package Overview in human-readable and JSON formats and includes information required by MAS-CSO-TPR among its listed inputs. The CPO note preserves applicability: information from a listed rule is not required where that rule does not apply. [FedRAMP Certification Package Overview](https://www.fedramp.gov/2026/providers/20x/rules/certification-package-overview) Keep the applicable resource information consistent across the working record and the overview. The [JSON validation workflow](/blog/20x/fedramp-20x-json-schema-validation-workflow) can help check the machine-readable representation, while the [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) helps connect the explanation to support. ## Maintain the impact explanation when use changes As an operating practice, revisit the record when the resource's configuration, permissions, data flows or safeguards change. Assign a technical owner who can explain the actual use and identify when the existing rationale no longer fits. The MAS and CPO pages list July 4, 2026 for initial certification and January 1, 2027 for ongoing certification, with grace ending on the first independent assessment started after January 1, 2027. Keep that applicability context with your package work. A useful record makes the scope condition, reason for use and impact-reducing measures understandable together. It supports review of the offering's actual dependency rather than treating a vendor name as the conclusion. ### FedRAMP 20x: Which Adoption Date and Grace Period Applies? - URL: https://boundera.io/blog/20x/fedramp-20x-adoption-dates-grace-periods - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:32:06.786579+00:00 - Updated: 2026-10-10T23:33:50Z - Reading time: 3 minutes - Main question: Which adoption date or grace endpoint should a Class B or C provider use? - TL;DR: Start with the ruleset and certification situation. Initial applications use the obtaining date; existing providers should adopt by the maintaining date and need a corrective action plan if they have not. Adoption is mandatory by the grace endpoint, which may be a fixed date or an assessment-start trigger. - Excerpt: Choose the applicable ruleset date for initial or ongoing certification, distinguishing optional adoption, corrective-action planning and grace endpoints. FedRAMP 20x adoption dates and grace periods describe different decisions. For Class B and C program owners, first identify the ruleset and whether the offering is applying for initial certification or maintaining an existing certification. Then use the date associated with that situation. A single calendar entry called the FedRAMP deadline hides too much. Keep optional adoption, initial application, ongoing adoption and the grace endpoint distinct. ## Read the four date labels as separate conditions The official 20x deadline guidance defines the labels as follows. [FedRAMP 20x Deadlines](https://www.fedramp.gov/2026/providers/updating/deadlines/20x) - **Optional adoption:** providers may adopt the entire ruleset after the listed date for initial or ongoing certification. - **Obtaining initial certification:** an initial application after this date must have adopted the ruleset or certification will be denied. - **Maintaining ongoing certification:** existing providers should adopt by this date; if they have not, a corrective action plan to adopt by the grace endpoint is required to maintain certification. - **Grace period ends:** existing certified providers must adopt by this point or certification will be revoked. These definitions distinguish the ongoing adoption expectation from the final grace endpoint. They also make the initial-application condition separate from the treatment of an already-certified provider. ## Compare a fixed endpoint with an assessment trigger Current 20x rows illustrate why the calendar needs more than one type of trigger. [FedRAMP deadline table](https://www.fedramp.gov/2026/providers/updating/deadlines/20x) | Ruleset | Optional adoption | Initial certification | Ongoing certification | Grace endpoint | | --- | --- | --- | --- | --- | | Vulnerability Detection and Response | July 4, 2026 | December 7, 2026 | December 7, 2026 | March 7, 2027 | | Vulnerability Evaluation and Reporting | July 4, 2026 | December 7, 2026 | December 7, 2026 | March 7, 2027 | | Certification Package Overview | July 4, 2026 | July 4, 2026 | January 1, 2027 | First independent assessment started after January 1, 2027 | For the overview ruleset, preserve the word started. Replacing the trigger with an assessment completion date would change what the source says. For VDR and VER, record the actual fixed grace date rather than deriving it from an assessment schedule. ## Build a calendar around the offering's situation The following are suggested internal planning fields, not an official calendar template: 1. The offering, class, certification situation and applicable ruleset. 2. The source version and the relevant date labels. 3. The adoption work still open and the responsible owner. 4. The evidence that will establish adoption. 5. Any applicable corrective-action work and assessment-start trigger. For an existing offering, use the ongoing-adoption definition to identify when corrective-action planning becomes necessary if work remains incomplete. Keep that planning distinct from the final adoption evidence. For an initial application, use the initial-certification condition instead of assuming an ongoing grace period extends it. The [assessment freshness guide](/blog/20x/fedramp-20x-refreshing-initial-assessment) addresses a separate timing question: the age of the package evidence and independent assessment being supplied. ## Review changes against the source, not the announcement date As an operating practice, compare updated source wording and the actual date fields before changing the calendar. A recent page or announcement date does not itself establish a new adoption deadline. Keep your task dates and evidence references connected to the ruleset entry. The [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) can help organize the supporting work. A usable calendar tells each owner which condition applies, what adoption remains to be done and what event ends the available grace. ### FedRAMP 20x: When Service Metadata Belongs in Assessment Scope - URL: https://boundera.io/blog/20x/fedramp-20x-metadata-assessment-scope - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:30:59.716198+00:00 - Updated: 2026-10-10T23:33:24Z - Reading time: 3 minutes - Main question: When does metadata belong in a Class B or C offering's assessment scope? - TL;DR: Separate FRD-FCD's data definition from MAS-CSO-IIR's resource scope test. MAS-CSO-MDI requires metadata inclusion only if IIR applies. Trace actual content, use and security impact, and preserve contractual ownership and protection caveats rather than relying on a telemetry label. - Excerpt: For Class B and C, distinguish provider-generated metadata from federal customer data, then evaluate the resource's actual handling and security impact. FedRAMP 20x metadata assessment scope depends on what the information and the systems handling it do. For Class B and C teams, separate the definition of federal customer data from the scope test for resources that handle or can affect that data. A telemetry label does not settle either question. Trace the information's origin, actual contents and downstream use before deciding how the scope rule applies. ## Separate data ownership from resource scope FRD-FCD defines federal customer data as electronic information and materials an agency or its authorized users supply for processing or storage. It excludes provider-generated account information, service metadata, analytics, telemetry and similar metadata. Its note preserves an important caveat: agency agreements may require protection of additional data or transfer ownership of telemetry or usage data, and it directs providers to consult a lawyer familiar with those agreements when determining scope. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/#federal-customer-data) Use that definition to examine the actual information rather than relying on the name of the destination system. If a log includes agency-supplied content, examine that content directly. Calling the record telemetry does not explain its origin or ownership. Route uncertain contractual ownership and protection questions to the responsible legal and contract owners. ## Apply the conditional metadata rule MAS-CSO-MDI says providers MUST include metadata, including metadata about federal customer data, in the Minimum Assessment Scope ONLY IF MAS-CSO-IIR applies. IIR requires the offering's assessed resource set to include resources likely to handle federal customer data or likely to affect its confidentiality, integrity or availability within the offering. [FedRAMP Minimum Assessment Scope](https://www.fedramp.gov/2026/providers/20x/rules/minimum-assessment-scope) Preserve the conditional relationship. Provider-generated metadata is not categorically outside assessment scope simply because it differs from federal customer data. At the same time, the rule does not automatically include every metadata record regardless of its relationship to the offering. The MAS page lists July 4, 2026 for initial certification and January 1, 2027 for ongoing certification, with grace ending on the first independent assessment started after January 1, 2027. Keep the Class B or C applicability and source version with the decision. ## Trace the metadata's operational role The following questions are an editorial analysis aid: - Which values are supplied by the agency, and which are generated by the provider? - Does the record contain copied content as well as descriptive metadata? - Which systems can read, change or act on the information? - What permissions or operational decisions depend on it? - Could the resource handling it affect federal customer data under the IIR test? For example, a record used only for one reporting purpose and a record that drives an access decision may have different relationships to the offering's security. Investigate that relationship; the example does not automatically place either resource inside or outside scope. Save the relevant data-flow and configuration references with the rationale. The [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) can help make that support retrievable. ## Keep the explanation aligned with the implementation As a working practice, revisit the decision when collection expands, record contents change or a downstream system begins using the information for a new purpose. A previous scope explanation may no longer describe the actual resource and its effects. For related outside-resource documentation, use the [package supplement guide](/blog/20x/fedramp-20x-package-supplements-app-materials). Keep the scope analysis focused on the operating model and the IIR condition before choosing where to present the material. A useful decision explains the information's origin, relevant ownership conditions and relationship to federal customer data, with enough implementation evidence for another reviewer to follow the reasoning. ### FedRAMP 20x: Assign Vulnerability PAIN Ratings from Customer Effects - URL: https://boundera.io/blog/20x/fedramp-20x-pain-rating-customer-effects - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:29:52.595586+00:00 - Updated: 2026-10-10T23:32:30Z - Reading time: 3 minutes - Main question: How should Class B and C teams assign vulnerability PAIN ratings from customer effects? - TL;DR: VER-EVA-EPA requires contextual likely-impact estimation and an N0–N5 rating. Apply the defined customer effect and agency count separately. Unknown adverse effects are treated as debilitating until proven otherwise; that does not establish agency count. N0 is an impact category, distinct from false-positive classification. - Excerpt: Estimate Class B and C vulnerability impact using the current N0–N5 categories, defined customer effects and evidence of affected agency use. A FedRAMP 20x vulnerability PAIN rating connects the likely effect of exploitation to the agencies using the offering. For Class B and C teams, start with the customer effect and the affected agency use, then apply the current N-rating definitions. The current rule includes N0, added in the October 5, 2026 update. Preserve that option and its wording while keeping impact, exploitability, reachability and treatment status distinct. ## Apply the current N0 through N5 categories VER-EVA-EPA requires contextual evaluation of detected vulnerabilities to estimate the likely potential agency impact of exploitation and assign a Potential Agency Impact N-rating. The following table paraphrases its current categories. [FedRAMP Vulnerability Evaluation and Reporting](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting) | Rating | Expected effect of exploitation | | --- | --- | | N0 | Adverse effects on agencies using the offering are extremely unlikely. | | N1 | Minimal effects could be expected for one or more agencies. | | N2 | Narrow effects could be expected for one or more agencies. | | N3 | A disruptive effect could be expected for one agency. | | N4 | A debilitating effect could be expected for one agency, or a disruptive effect for more than one federal agency. | | N5 | A debilitating effect could be expected for more than one agency. | Write down the effect and agency scope supporting the selected row. Treat them as separate parts of the explanation: the severity of the customer effect does not, by itself, establish how many agencies are affected. ## Use the defined customer effects precisely FedRAMP's definitions distinguish the effects as follows. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/) - **Minimal:** an unwanted effect noticeable only to some users, including minor inconvenience such as reduced performance. - **Narrow:** interrupted use for some users for less than 12 hours, or compromised confidentiality or integrity of an extremely limited amount and type of federal customer data. - **Disruptive:** interrupted use for many users for less than 24 hours, or compromised confidentiality or integrity of large amounts or many types of federal customer data. - **Debilitating:** interrupted use for most users, or compromised confidentiality or integrity of most federal customer data. FRD-DCE also says an unknown adverse customer effect should be treated as debilitating until proven otherwise. Keep that treatment of uncertainty separate from the question of how many agencies are affected. Use the source's qualitative terms rather than inventing percentage boundaries for some, many or most users. ## Keep N0 separate from other classifications The October 5 VER-EVA-EPA changelog says it clarified likely impact and added PAIN0. The rule's N0 category describes exploitation being extremely unlikely to have adverse agency effects. It is an impact category. [FedRAMP VER rules](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting) FRD-FPV separately requires that a false-positive vulnerability is not and was not present, and excludes remediated or fully mitigated vulnerabilities from that classification. Apply those conditions independently instead of deriving a false-positive result from an N0 label. [FedRAMP false-positive definition](https://www.fedramp.gov/2026/definitions/#false-positive-vulnerability) For related evaluations, see the [internet-reachability guide](/blog/20x/fedramp-20x-internet-reachability-payload-tracing) and [mitigation versus remediation guide](/blog/20x/fedramp-20x-mitigation-versus-remediation-status). Keep your working record's impact estimate, exposure rationale and treatment evidence distinguishable. ## Make the estimate reviewable as conditions change A useful internal record can capture the affected service, customer effect, agency-use evidence, uncertainty, selected rating and evaluation date. These are editorial fields for explaining the decision. Link the rating to the observations and assumptions that support it, then revisit those assumptions when treatment or customer use changes. The VER page lists optional adoption on July 4, 2026, initial and ongoing certification adoption on December 7, 2026, and a grace-period end of March 7, 2027. Preserve that applicability context in the evaluation process. The useful output is a rating another analyst can reproduce from the customer-effect explanation and agency scope, with uncertainty visible rather than hidden behind a number. ### FedRAMP 20x Class C: Organize Shared and Per-Service Package Materials - URL: https://boundera.io/blog/20x/fedramp-20x-shared-per-service-package-materials - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:28:43.868656+00:00 - Updated: 2026-10-10T23:31:10Z - Reading time: 3 minutes - Main question: How can Class C providers organize shared and per-service certification materials? - TL;DR: CDS-CSO-PSM permits Class C per-service materials and encourages a comprehensive shared set with separate information for unique service aspects. Use an index and stable references to make the structure usable. Keep service organization distinct from outside-resource supplements and report history. - Excerpt: Organize Class C package materials around shared references and service-specific differences so agency customers can find the information relevant to their use. FedRAMP 20x per-service certification materials can help an agency find the information relevant to the services it actually adopts. For a Class C provider, organize common material once and make the unique aspects of each service easy to identify. The practical challenge is navigation and consistency. A customer should be able to move from a service name to its relevant material without reading duplicate descriptions that drift apart when the offering changes. ## Understand the Class C option CDS-CSO-PSM says Class C providers MAY supply per-service Certification materials. Its notes say providers determine separate services based on improving the experience of agencies that may adopt only some services. They encourage a single comprehensive set of shared material, with separate material for each service's unique aspects, to reduce burden. [FedRAMP Certification Data Sharing](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing) This is an option for organizing material. Use it to make the relationship between common and service-specific information clearer. The cited rule concerns the supplied materials; maintain the offering's scope explanation alongside that structure. The CDS page lists July 4, 2026 for initial certification and January 1, 2027 for ongoing certification, with grace ending on the first independent assessment started after January 1, 2027. Keep the Class C applicability and timing with your implementation decision. ## Start from the customer's service choices As an implementation exercise, list the services an agency can adopt and the questions it needs answered for each. Identify which explanations are common and which differ in a way that matters to customer use. For example, two services may use the same workforce access process but expose different customer configuration options. A common reference can describe the shared process, while service-specific material explains the different settings. This is an organizational example, not an official division of package content. A useful index can contain the service name, shared references, unique material, current version, owner and access instructions. These suggested fields help a reader understand which pieces to combine. ## Manage shared changes through references Give each shared document a clear owner and stable reference. When it changes, check the service-specific material that relies on it. If a service has an exception to the common explanation, make the difference explicit rather than duplicating the whole document with a small hidden edit. In an internal review, choose one service and follow its references as a customer would. Can the reader tell which common material applies, what is unique, and where to ask a question? Then choose a second service and check whether the shared references still communicate the same version and meaning. The [agency onboarding guide](/blog/20x/fedramp-20x-agency-onboarding-package-handoff) can help connect this navigation to the customer's actual configuration and operating responsibilities. ## Distinguish service organization from other package views Material about resources outside the offering has a separate rule: MAS-CSO-SUP permits supplements for those resources, which are not certified and must be clearly marked and separated. [FedRAMP Minimum Assessment Scope](https://www.fedramp.gov/2026/providers/20x/rules/minimum-assessment-scope) Use the [supplement guide](/blog/20x/fedramp-20x-package-supplements-app-materials) for that distinction. Use the [package history guide](/blog/20x/fedramp-20x-package-history-report-snapshots) for retrieving the data aligned to earlier reports. As a design practice, label these views by their purpose: the current material relevant to a service, supplemental information about outside resources, and historical material associated with a report. Keeping those purposes visible makes the package easier to use and maintain as the offering grows. ### FedRAMP 20x False Positives: Document the Vulnerability Decision - URL: https://boundera.io/blog/20x/fedramp-20x-false-positive-vulnerability-decisions - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:27:48.459119+00:00 - Updated: 2026-10-10T23:30:03Z - Reading time: 3 minutes - Main question: How should Class C teams document a false-positive vulnerability decision? - TL;DR: FRD-FPV requires that the vulnerability is not and was not present; remediated or fully mitigated vulnerabilities cannot also be false positives. Preserve evidence of the relevant operating state. VER-EVA-EFP recommends false-positive evaluation, while VER-EVA-ELX separately requires likely-exploitability evaluation. - Excerpt: For Class C vulnerability review, separate a false positive from low exploitability or completed treatment and retain evidence of the relevant resource state. FedRAMP 20x false positive vulnerabilities need a precise explanation of the resource's actual state. For Class C analysts, an unfavorable scanner result, low exploitability and successful remediation are different questions. Record why the detection does or does not describe a vulnerability that was present. The decision should be understandable from the evidence, not just from a suppression label in a scanner console. ## Use the false-positive definition with all its conditions FRD-FPV defines a false positive as a detected vulnerability not actually present in an exploitable state in the resource. Its notes include vulnerable code that exists but is not loaded, running or otherwise in the operating state needed for exploitation. The definition also says the classification applies only if the vulnerability is not and was not present: a remediated or fully mitigated vulnerability cannot also be a false positive. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/#false-positive-vulnerability) Read the present and historical conditions together. Finding that software is not running today does not, by itself, establish that the vulnerability was never present. Investigate the state relevant to the detection and the changes made afterward. For example, if an engineering change removed the weakness after it was detected, evaluate the treatment state using the appropriate definition. Do not rewrite that sequence as a false positive merely because the latest result is clean. ## Keep false-positive review separate from exploitability For Class C, VER-EVA-EFP says providers SHOULD evaluate detected vulnerabilities in the offering's context to determine whether they are false positives. VER-EVA-ELX separately says providers MUST evaluate whether detected vulnerabilities are likely exploitable. Preserve the different force and purpose of those provisions. [FedRAMP Vulnerability Evaluation and Reporting](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting) FRD-LEV's likely-exploitability definition includes the vulnerability not being fully mitigated, reachability by a likely threat actor, and a likely adverse impact from exploitation by an actor with knowledge of the vulnerability. That is a distinct test from whether the vulnerability is not and was not present under FRD-FPV. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/#likely-exploitable-vulnerability-lev) Use the [mitigation and remediation guide](/blog/20x/fedramp-20x-mitigation-versus-remediation-status) to keep treatment states accurate, and the [internet-reachability guide](/blog/20x/fedramp-20x-internet-reachability-payload-tracing) for the separate payload-path evaluation. ## Preserve the evidence behind the decision A practical working record can include the resource identity, original detection, relevant software and runtime state, historical evidence, evaluation rationale and owner. These are editorial suggestions for making the decision inspectable. Ask the reviewer to connect the evidence to the specific condition in the definition. A package version, runtime observation or configuration record may answer part of the question; explain what it establishes and what it does not. Preserve uncertainty if the historical state cannot yet be established. If your tooling suppresses repeated detections, retain a route back to the rationale and supporting evidence. The suppression action should not become the only surviving record of the analysis. ## Revisit decisions when the relevant state changes As an engineering practice, tie reconsideration to changes that affect the basis of the decision, such as a component becoming active or a different execution path being used. This is a suggested review trigger, not an additional official review interval. The VER page lists optional adoption on July 4, 2026, initial and ongoing certification adoption on December 7, 2026, and a grace-period end of March 7, 2027. Keep the applicable source version with your evaluation process. A useful false-positive record explains why the definition fits, preserves the evidence of the relevant state and makes a later change easy to reassess. ### FedRAMP 20x Assessment Findings: Preserve the Assessor's Meaning - URL: https://boundera.io/blog/20x/fedramp-20x-preserving-assessor-findings - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:26:42.516831+00:00 - Updated: 2026-10-10T23:29:07Z - Reading time: 3 minutes - Main question: How should Class B and C providers include assessor findings without changing their meaning? - TL;DR: IVV-CSO-ICP permits formatting and presentation changes while prohibiting changes to underlying intent. IVV-IAS-VIP requires assessor verification of inclusion without inappropriate modification. Keep provider and assessor records distinct and preserve qualifications, disagreements and subsequent responses. - Excerpt: Keep Class B and C provider statements, assessor findings and later responses distinct while adapting assessment results for the maintained package. FedRAMP 20x assessor findings integrity depends on preserving what the assessor actually concluded when assessment results become part of the maintained package. For Class B and C providers, a shared evidence platform can support collaboration while keeping provider statements, independent findings and later responses distinct. The practical risk is a presentation change that quietly alters meaning: a qualification disappears, a disagreement becomes an unqualified pass, or later remediation is written as though the original finding never existed. ## Preserve intent while adapting presentation IVV-CSO-ICP requires providers to include independent assessment results in the Certification Package without inappropriate modification. Its note defines inappropriate modification as changing the underlying intent of the assessor's content; presentation and formatting changes are permitted as needed. [FedRAMP provider IVV rules](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation) The corresponding assessor rule, IVV-IAS-VIP, requires assessors to verify that the information they supplied is included without inappropriate modification. Keep both responsibilities visible when moving findings into the package. [FedRAMP assessor IVV rules](https://www.fedramp.gov/2026/assessors/rules/independent-verification-and-validation) The provider IVV page lists July 4, 2026 for initial certification and January 1, 2027 for ongoing certification, with grace ending on the first independent assessment started after January 1, 2027. This article addresses the Class B and C provider scope. ## Keep the records distinct in a shared platform Official 20x assessment guidance permits provider and assessor work in the same platform, including assessment feedback beside provider results. It says their records must remain distinct and the provider should not edit the substance of assessor findings. [FedRAMP Approaching 20x Assessments](https://www.fedramp.gov/2026/assessors/fedramp-assessments/20x) As implementation practices, use clear author attribution, separate record types and appropriate edit permissions. Preserve the assessor's original contribution and compare it with the version presented in the package. These are design suggestions, not a requirement to purchase or operate separate platforms. For example, a provider response can describe a corrective change beside an earlier finding. Give the response its own date, author and evidence references so a reader can distinguish the original conclusion from subsequent work. ## Check summaries for lost qualifications FedRAMP's assessment guidance says the provider includes assessment summaries in the Security Decision Record and Certification Package Overview, and the assessor verifies that their meaning was not changed. It also tells assessors to describe unsupported, failed or disputed matters and relevant risks or limits. [FedRAMP Performing Assessments](https://www.fedramp.gov/2026/assessors/fedramp-assessments) During your internal comparison, look for changes to scope, uncertainty, evidence limits and disagreement. The following are editorial review questions: - Does the summary cover the same resources and time period as the finding? - Are limitations and unresolved questions still visible? - Can a reader identify which statement belongs to the provider and which to the assessor? - Does later treatment appear as a subsequent event rather than a rewritten original conclusion? The [mitigation and remediation guide](/blog/20x/fedramp-20x-mitigation-versus-remediation-status) can help keep the description of later treatment accurate. ## Verify the final presentation, including exports Have the assessor inspect the actual representation that will be included in the package. As an implementation exercise, compare both the human-readable view and any export used to convey the result. A correct source record can still be presented incompletely by a summary or transformation. Retain the version references and the evidence of the assessor's verification in your own workflow. Use the [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) to keep those references usable. The result should make the finding, the provider's response and the subsequent state understandable without changing who said what. ### FedRAMP 20x Package History: Retain Snapshots for Ongoing Reports - URL: https://boundera.io/blog/20x/fedramp-20x-package-history-report-snapshots - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:25:35.260451+00:00 - Updated: 2026-10-10T23:27:56Z - Reading time: 3 minutes - Main question: How should Class B and C package owners retain history aligned to Ongoing Certification Reports? - TL;DR: CDS-CSO-HAD requires report-aligned Certification Data snapshots to remain available to all necessary parties for the duration of certification. Its note exempts reconstruction before the first Ongoing Certification Report. Use an index and retrieval exercises to preserve the relationship as the live package changes. - Excerpt: Retain report-aligned Class B and C Certification Data snapshots and test their retrieval while continuing to update the live package. FedRAMP 20x package history snapshots help a reviewer understand the certification data associated with an earlier Ongoing Certification Report while the live package continues to change. For Class B and C package owners, design retrieval around the report and the corresponding historical state. A link that always opens today's document may be useful for current operations, but it does not explain which version supported an earlier report. Preserve that relationship explicitly in your history process. ## Retain the data aligned to each ongoing report CDS-CSO-HAD requires providers to supply snapshots of Certification Data aligned to Ongoing Certification Reports to all necessary parties. Those snapshots MUST remain available for the duration of certification. Its note says historical snapshots do not need reconstruction for periods before the provider's first Ongoing Certification Report, but should be maintained for all subsequent reports. [FedRAMP Certification Data Sharing](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing) Keep both parts of the rule visible: alignment with the report and availability to the necessary parties. A retained archive that nobody can locate or retrieve is a weak operational implementation of that purpose. The CDS page lists July 4, 2026 for obtaining initial certification and January 1, 2027 for maintaining ongoing certification, with grace ending on the first independent assessment started after January 1, 2027. This article addresses the Class B and C provider scope. ## Build a report-to-snapshot index As an implementation aid, give each report a corresponding history entry containing the report reference, snapshot identity, capture context, retained version references and retrieval location. Identify an owner for maintaining the relationship and resolving access problems. These are editorial fields, not an official bundle format. Select storage and versioning mechanisms that let you retrieve the historical state your process identifies. If a snapshot relies on linked records, check whether those links resolve to retained versions or silently open current content. For example, a report may reference a Security Decision Record that is updated later. Keep a way to retrieve the record associated with that report while still making the current version easy to find. Label both views clearly so a reader does not mistake an older decision for today's state. ## Test retrieval through the intended access path Choose an earlier report and ask another team member to retrieve its aligned data using the normal access process. The following exercise is practical advice: 1. Find the report without relying on the original author's memory. 2. Open its snapshot and inspect several version references. 3. Confirm that historical links have not drifted to current content. 4. Check access for the intended reader role. 5. Record and resolve gaps in the index or retained material. The [trust-center scope guide](/blog/20x/fedramp-20x-trust-center-agency-scope) covers broader sharing responsibilities. Use the [sensitive-data review guide](/blog/20x/fedramp-20x-package-sharing-sensitive-details) when preparing information for disclosure. ## Keep different history needs distinguishable Maintain separate descriptions in your operating documentation for report-aligned package snapshots, raw measurement history, vulnerability activity and access records. This is an organizational suggestion: it helps the team check the rule that governs each kind of information instead of assuming one archive answers every retention question. For this workflow, the cited HAD obligation ties snapshots to Ongoing Certification Reports and availability to the duration of certification. Build your report process so the snapshot relationship is created and tested as part of the work, then remains retrievable as the live package evolves. ### FedRAMP 20x Agency Monitoring: Follow Inherited Packages - URL: https://boundera.io/blog/20x/fedramp-20x-agency-monitoring-inherited-packages - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:24:21.845351+00:00 - Updated: 2026-10-10T23:27:46Z - Reading time: 3 minutes - Main question: How should agencies and provider security teams track inherited packages that affect agency use of a 20x service? - TL;DR: Agencies are responsible for understanding and monitoring inherited FedRAMP packages where they affect agency use. Map the dependency to that use, keep relevant references and contacts available, and record the agency's review decision. FedRAMP evidence supports the agency monitoring program without replacing it. - Excerpt: Connect inherited package information to the agency's actual reliance, with clear references, access routes, review owners and recorded decisions. FedRAMP 20x inherited package monitoring asks an agency to understand dependencies that affect its use of a cloud service. If the direct provider relies on controls from another package, the agency's monitoring discussion should connect that inheritance to the agency system rather than stop at the direct provider's name. Provider customer-security teams can help make the relationship understandable. The agency retains its monitoring and risk decisions; the practical handoff is a usable explanation of the dependency, supporting references and a route for questions. ## Follow inheritance where it affects agency use FedRAMP's ongoing-authorization guidance states that when an agency system uses an offering that inherits controls from another FedRAMP package, the agency is also responsible for understanding and monitoring that inherited package where it affects agency use. The guidance also says certification provides reusable security information without replacing the agency's own continuous monitoring program. [FedRAMP Ongoing Agency Authorization](https://www.fedramp.gov/2026/agencies/use/ongoing) Preserve the connection to use. The point is to understand how the inherited capability affects the agency's service configuration, information or operating assumptions. Official agency-use guidance encourages reuse of certification materials to the greatest extent possible instead of recreating the provider assessment. [FedRAMP Using a Certified Cloud Service](https://www.fedramp.gov/2026/agencies/use) ## Map the dependency to the agency's reliance For an internal working record, connect three things: the direct service, the inherited capability and the part of agency use that depends on it. Suggested editorial fields include: - The direct offering and the relevant inherited package reference. - The capability or control relationship the agency relies on. - The service feature, configuration or data flow affected by that reliance. - The material used to understand the relationship and its version. - The owner for questions and the route for obtaining appropriate access. - The agency review decision or open question resulting from the information. This map is a coordination aid, not an official artifact specification. Confirm how the intended reviewer can obtain the relevant material rather than assuming that a reference automatically grants unrestricted access to every upstream document. The [onboarding handoff guide](/blog/20x/fedramp-20x-agency-onboarding-package-handoff) covers the initial connection between the provider package and customer implementation. Keep this ongoing map focused on the inherited dependencies and changes that matter after onboarding. ## Turn new information into a review question The official ongoing guidance tells agencies to review Ongoing Certification Reports and other certification data for changes affecting the risk tolerance documented in their authorization. It recommends vulnerability review at intervals appropriate to the agency system's risk, using automated processing where possible. [FedRAMP Ongoing Agency Authorization](https://www.fedramp.gov/2026/agencies/use/ongoing) For example, if new information concerns an inherited capability, ask which agency use depends on it, whether the prior assumption still holds and who can resolve uncertainty. These questions are an implementation approach; they do not establish a universal review cadence. Keep the information received separate from the agency's conclusion about it. A provider can explain the dependency and its own response, while the agency evaluates the consequence for its authorized system. ## Keep contact paths and decisions durable FedRAMP's guidance encourages active agency participation in collaborative monitoring, responsiveness to provider communications and contact paths that survive personnel changes. It also emphasizes that provider assurance does not replace agency monitoring of agency-managed settings, accounts, logs and other responsibilities. [FedRAMP ongoing guidance](https://www.fedramp.gov/2026/agencies/use/ongoing) As a working practice, assign role-based owners and preserve the context of unresolved questions when staff change. Use the [collaborative monitoring guide](/blog/20x/fedramp-20x-collaborative-monitoring-agency-roles) for the broader division of responsibilities. A useful inherited-package review ends with an understandable relationship, the information considered and a recorded agency decision or next action. That keeps dependencies connected to the actual system being monitored. ### FedRAMP 20x Package Supplements: Separate Apps from the Certified Offering - URL: https://boundera.io/blog/20x/fedramp-20x-package-supplements-app-materials - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:24:48.290036+00:00 - Updated: 2026-10-10T23:25:57Z - Reading time: 3 minutes - Main question: How should Class B and C providers share supplemental app materials without blurring certification scope? - TL;DR: Make the scope decision first. MAS-CSO-SUP permits material about resources outside the offering in a supplement, but those resources are not certified and must be marked and separated. Preserve the specific delivery and operating-model conditions in the MAS-CSO-IIR software note. - Excerpt: Separate Class B and C package supplements from the certified offering, preserving the operating-model conditions for agency-installed software. FedRAMP 20x package supplemental materials can help an agency understand related software without blurring what is certified. For Class B and C providers, begin with the scope decision, then clearly separate material about resources outside the cloud service offering. An app's product name or its location in a document library does not explain its operating model. Establish who operates the resource, where it is delivered and how it relates to the offering before deciding how to present its security material. ## Make the scope decision before assembling the supplement MAS-CSO-IIR requires providers to identify the offering's resources for assessment, including resources likely to handle federal customer data or affect the confidentiality, integrity or availability of that data in the offering. Its notes address software delivered separately for installation on agency systems and not operated in a shared responsibility model, typically including clients or agents not fully managed by the provider. Software meeting those stated conditions is outside the offering for FedRAMP. [FedRAMP Minimum Assessment Scope](https://www.fedramp.gov/2026/providers/20x/rules/minimum-assessment-scope) Preserve the conditions when explaining the distinction. The note does not say every resource called an agent or client is automatically excluded. If the product includes connected cloud resources, assess their relationship to the offering under the scope rule instead of treating the desktop or mobile label as the answer. For an internal review, record the resource's operating model, the responsible parties and the information flows that explain the scope decision. These are practical documentation suggestions. ## Mark and separate resources outside the offering MAS-CSO-SUP permits additional material about resources outside the offering in a Certification Package supplement. Those resources will not be FedRAMP Certified and MUST be clearly marked and separated from the offering. The note explains that useful examples include app security materials and supplemental collateral. [FedRAMP MAS-CSO-SUP](https://www.fedramp.gov/2026/providers/20x/rules/minimum-assessment-scope) A useful presentation gives the reader the scope distinction before they open a document. As an editorial label, consider: “Supplemental information about a resource outside this certified cloud service offering.” Adapt the wording to the actual resource and scope decision; this is not an official label template. Keep navigation clear enough that a customer does not mistake the supplement's contents for the list of certified services. The [agency onboarding guide](/blog/20x/fedramp-20x-agency-onboarding-package-handoff) can help connect those materials to the customer's own configuration and operating responsibilities. ## Build a small supplement index Suggested index fields include the resource name and version, its relationship to the offering, the relevant scope explanation, the security material available and a contact for questions. Link to the source document instead of maintaining several disconnected copies. For example, an agency-installed client might have its own deployment guidance and update process. The supplement can organize that information while making clear that inclusion in the package does not certify the client. The provider should still describe the certified cloud services the client connects to accurately. Apply the [sensitive package-data review](/blog/20x/fedramp-20x-package-sharing-sensitive-details) to the documents being shared. A resource's placement in a supplement does not eliminate the need to consider the information disclosed. ## Recheck the presentation when the product changes As an operating practice, revisit the scope explanation when management responsibility, delivery model or data flows change. Review customer-facing descriptions and package navigation together so a stale label does not outlive the decision it was meant to explain. The MAS page lists July 4, 2026 for obtaining initial certification and January 1, 2027 for maintaining ongoing certification, with the grace period ending on the first independent assessment started after January 1, 2027. Keep the applicable timing and source version with the scope review. The supplement is useful when the customer can distinguish the certified offering, the related external resource and the documentation that helps them use both appropriately. ### FedRAMP 20x: Refreshing an Aging Initial Assessment - URL: https://boundera.io/blog/20x/fedramp-20x-refreshing-initial-assessment - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:22:13.269123+00:00 - Updated: 2026-10-10T23:24:33Z - Reading time: 3 minutes - Main question: How can Class B and C providers address an aging initial assessment before submission? - TL;DR: Track package freshness and assessment age separately. FRC-APP-FCP uses the previous seven days for provider verification and validation; B/C FRC-APP-FIA uses three months for the independent assessment. FRC-APP-USA permits recognized-assessor change review instead of full reassessment unless the stale assessment is more than nine months old. - Excerpt: Separate the package's seven-day freshness from the Class B and C assessment age, then evaluate the recognized-assessor change-review option and its limit. When a submission slips, FedRAMP 20x initial assessment freshness becomes a scheduling and evidence problem. For Class B and C providers, check the age of the independent assessment separately from the freshness of the package you plan to submit. The current rules provide a conditional way to freshen a stale assessment through a recognized assessor's review of changes. Start with the original assessment, the current service state and the work performed between them. ## Track the package and assessment separately FRC-APP-FCP requires a fresh initial Certification Package showing the offering's current status as verified and validated by the provider within the previous seven days. FRC-APP-FIA separately requires Class B and C providers to supply a fresh initial independent assessment completed by a FedRAMP Recognized independent assessment service within the previous three months. [FedRAMP Certification rules](https://www.fedramp.gov/2026/providers/20x/rules/fedramp-certification) These provisions refer to different work by different parties. A recent provider verification and validation does not describe when the independent assessment was completed. Put both dates and their supporting evidence on your submission readiness view. For example, a provider may have current operational evidence while the independent assessment is aging because the application was delayed. Conversely, a recently completed assessment does not itself explain whether the package reflects the current service state within the provider's seven-day window. ## Apply the stale-assessment option with its limit FRC-APP-USA permits providers to freshen a stale initial independent verification and validation assessment by having a FedRAMP Recognized independent assessment service review changes between the original assessment and the offering's current status instead of a full reassessment. The option does not apply if the stale assessment is more than nine months old. The rule uses MAY. [FedRAMP FRC-APP-USA](https://www.fedramp.gov/2026/providers/20x/rules/fedramp-certification#updating-stale-assessments) Keep the recognized assessor's review at the center of the process. An internal review or an edited document date does not describe the work specified by this option. Discuss the original completion date and the actual changes with the assessor before assuming the option fits your submission plan. ## Prepare a dated change inventory As an implementation aid, organize the material the assessor will need to understand what changed. Suggested categories include service scope, architecture, configuration, evidence-generation logic, security decisions and unresolved findings. For each change, record: - The affected part of the offering and the date of the change. - The original assessment or evidence reference it relates to. - The current state and evidence demonstrating that state. - The owner who can explain the change and any remaining uncertainty. This inventory is preparation advice, not an official template. Keep it connected to the underlying records so a reviewer can investigate a change rather than rely on a summary alone. The [assessor expertise guide](/blog/20x/fedramp-20x-assessor-automation-expertise) covers technical questions for choosing an assessment partner. ## Recheck readiness against the planned submission After the assessment work is resolved, verify that the submission package and its provider verification and validation are current for the planned submission. Use the [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) to check retrieval and consistency of the supporting material. The FRC page lists July 4, 2026 for obtaining initial certification and January 1, 2027 for maintaining ongoing certification, with the grace period ending on the first independent assessment started after January 1, 2027. Keep those applicability dates distinct from the seven-day, three-month and nine-month provisions above. A useful readiness record shows the original assessment, any recognized-assessor change review, and the package's current verified and validated state. That makes the remaining work visible before another schedule change leaves the evidence out of date. ### FedRAMP 20x: Check Agency Contract Commitments Against Ongoing Duties - URL: https://boundera.io/blog/20x/fedramp-20x-agency-contract-commitments - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:21:03.179564+00:00 - Updated: 2026-10-10T23:22:42Z - Reading time: 3 minutes - Main question: How should provider teams review agency commitments against ongoing FedRAMP 20x responsibilities? - TL;DR: Map proposed commitments to the certification activities they affect and resolve conflicts with contract and security owners. FedRAMP guidance allows agency-specific requirements while warning against commitments that prevent ongoing compliance. Keep agency determinations and notifications for additional material requests separate. - Excerpt: Review proposed agency commitments against ongoing certification activities, then route operational conflicts and additional information requests to the right owners. Review FedRAMP 20x agency contract commitments before sales or delivery teams promise how the service will operate. An agency-specific request may be reasonable while still needing a check against the provider's ongoing certification activities, information sharing and ability to adopt rule changes. The practical aim is to identify operational conflicts early and put them in front of the responsible contract and security owners. Use the current FedRAMP guidance to frame that review and preserve the agency's separate responsibilities. ## Check additional commitments against ongoing duties FedRAMP's provider-responsibility guidance says agencies may require additional materials, capabilities or changes to an offering or its procedures based on agency-specific requirements. It describes this as expected and acceptable, while telling providers to avoid commitments that prevent them from meeting ongoing certification rules. [FedRAMP Cloud Service Provider Responsibilities](https://www.fedramp.gov/2026/responsibilities/providers) The guidance also places responsibility on providers for maintaining certification materials, sharing them with the relevant parties, performing ongoing activities, responding to FedRAMP and adopting rule changes as necessary. Read a proposed commitment against those actual activities. For example, ask whether a proposed approval dependency could delay a rule-driven update or whether a sharing restriction could interfere with supplying certification information to another necessary party. These are review questions, not conclusions about a particular agreement's legal effect. ## Build an operational obligation map An internal review can use a short record for each proposed commitment: | Review field | Question to resolve | | --- | --- | | Requested outcome | What does the customer need the service or team to do? | | Affected activity | Which maintenance, reporting, sharing or assessment process would change? | | Governing source | Which current rule, scope and timing apply to that activity? | | Delivery approach | Can the team fulfill the request while performing the certification activity? | | Decision owner | Who will resolve the operational and contractual questions? | This map is an editorial coordination tool. Keep the exact request and proposed operating approach attached so reviewers can assess the concrete commitment rather than a paraphrase that loses an important condition. The [agency onboarding guide](/blog/20x/fedramp-20x-agency-onboarding-package-handoff) can help distinguish customer configuration work from provider package and operating responsibilities. ## Route additional information requests through the right roles The Agency Use rules address requests beyond FedRAMP's required information. AGU-AGC-NAR says agencies MUST NOT require additional information or materials from certified offerings unless the agency head or an authorized delegate determines a demonstrable need and notifies FedRAMP. The rule excludes clarification requests and general questions about certification data from that restriction. [FedRAMP Agency Use rules](https://www.fedramp.gov/2026/agencies/rules/agency-use) AGU-AGC-NAI separately requires agencies to notify FedRAMP after requesting additional information or materials beyond those required by FedRAMP. Keep those agency determination and notification steps distinct from the provider's own delivery review. As a working practice, identify whether the request is for clarification, existing package access, additional material or an operational capability. Then route the question to the appropriate agency and provider owners. Do not assume every customer question is an additional-material requirement. ## Preserve the decision in the delivery handoff After the responsible owners resolve the request, carry the agreed operational approach into implementation planning. Record the service affected, the owner, relevant source references and any dependency that needs continued attention. Revisit the review if the scope or operating assumptions change. For sharing-related questions, use the [sensitive package-data guide](/blog/20x/fedramp-20x-package-sharing-sensitive-details) to keep the information useful while reviewing dangerous specifics. The goal is an agreement the delivery team understands and an operating process that can continue performing its certification work. ### FedRAMP 20x: Group Vulnerability Findings for Response - URL: https://boundera.io/blog/20x/fedramp-20x-grouping-vulnerability-findings - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:19:45.270067+00:00 - Updated: 2026-10-10T23:21:41Z - Reading time: 3 minutes - Main question: How should Class B and C teams group detected vulnerabilities for response? - TL;DR: VER-EVA-GRV recommends contextual evaluation for logical groups that improve response, applying VDR rules to the consolidated groups. Use a traceable parent-and-member record as an implementation aid. Keep response grouping separate from detection sampling and preserve meaningful differences between members. - Excerpt: Consolidate Class B and C response work around a documented rationale while preserving member detections, exposure differences and treatment evidence. FedRAMP 20x vulnerability grouping can turn repeated findings into a coherent response effort. For Class B and C teams, the useful question is whether a logical grouping of affected resources improves response while preserving the context needed to act on the weakness. A shared vulnerability identifier is a starting point for investigation. Before combining work, compare the affected resources, exposure, treatment and ownership so the consolidated record tells a coherent story. ## Apply the response-grouping recommendation VER-EVA-GRV says providers SHOULD evaluate detected vulnerabilities in the offering's context to identify logical groupings of affected resources that may improve response efficiency and effectiveness by consolidating further activity. It then applies FedRAMP Vulnerability Detection and Response rules to those consolidated groups rather than each detected instance. Preserve both the SHOULD force and the context-based purpose of the rule. [FedRAMP Vulnerability Evaluation and Reporting](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting) For an internal grouping decision, ask what work will become clearer or more effective. A common deployment change, common cause or shared treatment owner may be useful considerations. These are editorial evaluation prompts, not an official grouping formula. ## Keep the parent record connected to its members One practical implementation is a parent response record with links to the member detections. Preserve the source records and explain why they belong together. Suggested fields include: - The affected resource set and the detections included. - The reason consolidation improves the response. - Relevant differences in exposure, configuration or treatment state. - The owner, intended treatment and supporting evidence. - The original detection and evaluation references used in the response timeline. - Conditions that would cause a member to be separated or the group reconsidered. This structure is implementation advice. Avoid letting a newly created parent record overwrite historical timestamps in your own system. Keep dates and source references inspectable so consolidation does not obscure how the work developed. For example, two deployments may share a software weakness but require different treatment because one cannot accept the planned upgrade. A useful parent record would expose that difference and the remaining work rather than show a single unexplained complete status. ## Separate response grouping from detection sampling VDR-CSO-SIR addresses a different activity: it permits sampling effectively identical resources for vulnerability detection unless doing so reduces detection efficiency or effectiveness. VER-EVA-GRV addresses consolidation of response activity after evaluating detected vulnerabilities. [FedRAMP Vulnerability Detection and Response](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-detection-and-response) Use separate rationales for these decisions. A response group does not, by itself, demonstrate effective identity for detection sampling. The [sampling coverage guide](/blog/20x/fedramp-20x-vulnerability-sampling-coverage-plan) covers that decision and its conditions. Likewise, keep treatment status understandable within the group. The [mitigation and remediation guide](/blog/20x/fedramp-20x-mitigation-versus-remediation-status) can help prevent completed work on some members from being described as remediation of every member. ## Reassess the grouping when its assumptions change As an operating practice, review membership when a deployment changes, a new detection reveals a different context, or the planned treatment diverges. Ask whether the consolidated activity still improves the response. If the explanation no longer holds, revise the grouping and preserve the relationship to the earlier record. The VER page lists optional adoption on July 4, 2026, initial and ongoing certification adoption on December 7, 2026, and a grace-period end of March 7, 2027. Use the applicable class and adoption context when putting the rule into operation. A useful group lets a reviewer trace the response from a consolidated decision to the affected resources and evidence. It reduces repetitive coordination while keeping the differences that matter visible. ### FedRAMP 20x Accepted Vulnerabilities: What to Record and Report - URL: https://boundera.io/blog/20x/fedramp-20x-accepted-vulnerability-records - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:20:05.807259+00:00 - Updated: 2026-10-10T23:21:31Z - Reading time: 3 minutes - Main question: What should Class B and C providers record and report about accepted vulnerabilities? - TL;DR: Use the accepted-vulnerability definition and VER-TFR-MAV's 192-day evaluation threshold, including forecast non-completion. VER-RPT-AVI requires identification, evaluation, reachability, exploitability, current impact and acceptance information. Provider acceptance is separate from remediation and the agency's own risk decision. - Excerpt: Classify accepted vulnerabilities using intent and timing, then preserve the evaluation, current impact estimate and explanation in Class B and C reporting. FedRAMP 20x accepted vulnerability records should explain the weakness that remains and why the provider has classified it as accepted. For Class B and C teams, accepted is a defined reporting category; it is not another word for remediated or an indication that the agency has made its own risk decision. Build the record while the decision is being made. That makes the reason, evaluation and supporting evidence easier to preserve than reconstructing them after a reporting deadline. ## Classify acceptance using intent and timing FRD-ACV defines an accepted vulnerability as one the provider does not intend to fully mitigate or remediate, or one that has not or will not reach that state within the maximum overdue period referenced in the definition. FRD-ODV separately defines an overdue vulnerability as one the provider intends to fully mitigate or remediate but has not or will not do so within FedRAMP's recommended or required timeframes. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/#accepted-vulnerability) VER-TFR-MAV requires providers in the Class B and C scope discussed here to categorize any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as accepted. Preserve the forward-looking wording: a forecast that treatment will not finish within that period is relevant, not just the passage of day 192. [FedRAMP Vulnerability Evaluation and Reporting](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting) Read these provisions together. If the provider already does not intend full mitigation or remediation, the definition itself is relevant to classification. Treat 192 days as the stated rule threshold, not a reason to postpone recording a known decision. ## Include the accepted-vulnerability reporting information VER-RPT-AVI requires the following information about accepted vulnerabilities when reporting vulnerability detection and response activity. The list below paraphrases the rule; use the linked official rule and schema for implementation. [FedRAMP VER-RPT-AVI](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting#accepted-vulnerability-info) - The provider's internal tracking identifier. - Detection time and source, plus the time evaluation was completed. - Whether the vulnerability is internet-reachable and whether it is likely exploitable. - The current estimated Potential Agency Impact N-rating. - An explanation of why the vulnerability is accepted. - Supplementary information the provider determines will responsibly help agencies assess or mitigate the resulting risk to their federal customer data in the offering. Write the acceptance explanation so a reader can distinguish a deliberate treatment decision from a timing forecast. As an editorial practice, link it to the engineering rationale and evidence rather than filling the field with a generic accepted label. ## Preserve the difference between treatment and agency risk FedRAMP defines remediation as a vulnerability being eliminated or neutralized and no longer detected. A provider's accepted classification describes a different condition. The [mitigation and remediation guide](/blog/20x/fedramp-20x-mitigation-versus-remediation-status) explains the treatment distinction. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/#remediated-vulnerability) Separately, official agency-use guidance says the agency authorizing official accepts risk for the agency's specific use of the service. Do not present a provider's accepted-vulnerability label as that agency decision. [FedRAMP agency-use guidance](https://www.fedramp.gov/2026/agencies/use) The reporting rule above explicitly addresses accepted vulnerabilities. Keep the record available to the reporting process rather than using acceptance as an automatic removal condition. ## Review the record when its basis changes A practical internal review can check the treatment intent, forecast, present exposure, current impact estimate and explanatory evidence. Assign an owner for changes that affect the rationale. These are editorial operating suggestions, not a new official approval form. The VER page lists optional adoption on July 4, 2026, initial and ongoing certification adoption on December 7, 2026, and a grace-period end of March 7, 2027. Keep applicability and the version of the rule alongside your reporting implementation. Use the [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) to make the decision and its support retrievable. The record should tell a reviewer what remains, why it is accepted and what information supports that description. ### FedRAMP 20x Internet Reachability: Trace the Payload to the Vulnerability - URL: https://boundera.io/blog/20x/fedramp-20x-internet-reachability-payload-tracing - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:16:47.495879+00:00 - Updated: 2026-10-10T23:20:13Z - Reading time: 3 minutes - Main question: How should Class B and C teams evaluate internet reachability for vulnerabilities in private resources? - TL;DR: FRD-IRV includes specific vulnerable resources that can process triggering internet-origin payloads without a direct internet route. Trace the actual path and affected processing step. Keep reachability separate from likely exploitability and retain evidence for each conclusion. - Excerpt: Evaluate Class B and C vulnerability reachability by tracing internet-origin payloads to the affected resource, including indirect processing paths. A private address does not settle whether a vulnerability can be triggered by internet-origin data. For Class B and C teams evaluating a FedRAMP 20x internet reachable vulnerability, trace the payload to the specific vulnerable resource, including processing that happens behind a queue, upload service or application tier. The useful evidence is the data path and the vulnerable processing step. A network label alone is too coarse to explain that relationship. ## Apply the definition to the specific resource FRD-IRV defines an internet-reachable vulnerability as one in a machine-based resource that might be exploited or otherwise triggered by a payload originating on the public internet. Its notes include resources without a direct internet route that receive payloads or act on internet-triggered activity. They also limit reachability to the specific vulnerable resources processing the payload. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/#internet-reachable-vulnerability-irv) This definition supports two practical cautions. Do not classify a vulnerability as unreachable solely because the resource has no public address. Also, do not mark every resource on an internal network reachable merely because one component processes an internet-origin payload. Investigate the affected resource and processing path. ## Trace a candidate path before assigning the result For the Class B and C scope addressed here, VER-EVA-EIR requires evaluation of detected vulnerabilities in the offering's context to determine internet reachability. Its notes explain that a resource can receive a triggering payload indirectly through an application stack. [FedRAMP Vulnerability Evaluation and Reporting](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting) The following scenarios illustrate questions to investigate; they do not automatically classify a deployment: | Candidate path | Question for the evaluator | | --- | --- | | Public upload to private processing worker | Can the uploaded data reach the vulnerable parser in a form that might trigger the weakness? | | Public application to queue to downstream service | Does the queue preserve or transform the relevant payload, and which resource processes it? | | Public request through filtering and application logic | What evidence shows whether the triggering content reaches the vulnerable operation? | As an implementation practice, connect the evaluation to architecture references, relevant configuration and controlled observations of the data flow. Record uncertainty where the path is not yet understood. Avoid turning the presence of a queue or filter into an unsupported conclusion in either direction. ## Keep likely exploitability as a separate evaluation VER-EVA-ELX separately requires contextual evaluation of whether detected vulnerabilities are likely exploitable. FRD-LEV combines several conditions: the vulnerability is not fully mitigated, it is reachable by a likely threat actor, and a likely threat actor with knowledge of it would likely cause an undesired adverse impact through exploitation. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/#likely-exploitable-vulnerability-lev) Keep the internet-reachability rationale and the likely-exploitability rationale distinct in your working record. For example, knowing that a data path exists does not complete the rest of the exploitability analysis. The [mitigation and remediation guide](/blog/20x/fedramp-20x-mitigation-versus-remediation-status) helps keep the treatment state precise during that evaluation. The VER page lists optional adoption on July 4, 2026, initial and ongoing certification adoption on December 7, 2026, and a grace-period end of March 7, 2027. Keep these applicability dates with the rules used for the evaluation. ## Revisit the path when the service changes A useful internal review trigger is a change to the entry point, transformation, filtering behavior or processing resource used in the original rationale. This is an engineering suggestion, not an additional official review interval. Retain the resource identity, the evaluated weakness, the path considered and the evidence supporting the decision. Use the [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) to make those references retrievable. The result should let another evaluator understand why the classification applies to this vulnerability in this service context. ### FedRAMP 20x Agency Onboarding: Connect Your Package to the Customer System - URL: https://boundera.io/blog/20x/fedramp-20x-agency-onboarding-package-handoff - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:17:14.600458+00:00 - Updated: 2026-10-10T23:18:59Z - Reading time: 3 minutes - Main question: How should a 20x provider hand off package information for an agency customer's system authorization? - TL;DR: Identify the certified offering, share usable package references, and connect provider capabilities to customer configuration and operating responsibilities. The agency documents and authorizes its own information system and retains its risk decision. A handoff record is an implementation aid; the agency decides the outcome. - Excerpt: Connect the certified offering and provider evidence to the agency's configuration, integrations and operating responsibilities during onboarding. FedRAMP 20x agency onboarding works best when the handoff connects your package to the customer's actual use of the service. Give the agency a clear way to identify the certified offering, understand the capabilities it will rely on, and configure the responsibilities it owns. The provider package is reusable evidence. The agency still makes its own system authorization and risk decision. A useful handoff helps the customer describe that use without copying your entire package into its system documentation. ## Start with the agency system and the certified offering FedRAMP's agency-use guidance distinguishes certification of the cloud offering from authorization of the agency information system. It says the agency authorizing official accepts risk for the agency's specific use, including its information, configuration, integrations and agency-operated controls. It directs agencies to authorize the system using the offering as an external service rather than create a standalone ATO for the offering itself. [FedRAMP Using a Certified Cloud Service](https://www.fedramp.gov/2026/agencies/use) The same guidance tells agencies to confirm they are using the certified version and review the package, including certification type and class, inherited controls, provider responsibilities, secure configuration guidance and ongoing data. For the provider's handoff, begin with the exact offering and services the customer intends to use. Ask the customer to identify its intended integration and configuration so the discussion stays tied to a concrete deployment. ## Map capabilities to customer actions The official agency SSP guidance says to account for every selected control, describe agency implementation in detail and reference the provider package for capabilities the agency uses or relies on. It calls for one SSP for the agency information system rather than a separate agency SSP for each cloud service. [FedRAMP Agency System Security Plan](https://www.fedramp.gov/2026/agencies/use/initial/ssp) A provider-side handoff record can help organize that discussion. The following fields are editorial suggestions for that discussion: | Handoff topic | Useful provider contribution | Customer decision to clarify | | --- | --- | --- | | Service scope | Offering identity, service names and relevant package references | Which services the agency plans to use | | Identity | Supported configuration guidance and capability evidence | How the agency configures accounts, groups and its identity integration | | Logging | Event and export capability documentation | What the agency collects, reviews and responds to | | Shared operations | Applicable provider procedures and contact routes | Who owns customer-side activities and escalations | Use the [secure configuration guide article](/blog/20x/fedramp-20x-secure-configuration-guide-customer-settings) for the customer-settings part of this handoff. Avoid rewriting the configuration workflow into a second, potentially conflicting checklist. ## Share references that remain usable As an implementation practice, supply stable references to the relevant package material and note the version used in the onboarding discussion. Have the customer's intended readers exercise access before depending on those references in their documentation. Follow the [package-sharing review approach](/blog/20x/fedramp-20x-package-sharing-sensitive-details) when preparing material for the recipient. Keep the risk explanation useful and direct the customer to the appropriate access route for supporting evidence. For each open question, record which party will answer it and whether it concerns provider evidence or an agency implementation choice. This can keep a request for a customer-specific setting from becoming an unnecessary rewrite of the provider package. ## Connect onboarding to ongoing operation FedRAMP's agency-use guidance says agencies should monitor ongoing certification reports, vulnerability information, quarterly reviews and other certification data at intervals appropriate to their system's risk. Its SSP guidance also calls for updates when use, configuration, dependencies or relevant provider capabilities change. [FedRAMP agency-use guidance](https://www.fedramp.gov/2026/agencies/use) Before completing the handoff, identify the recipients for ongoing information and agree how implementation questions will reach the right owner. Our [collaborative monitoring guide](/blog/20x/fedramp-20x-collaborative-monitoring-agency-roles) explains the broader division of responsibilities. Treat onboarding completion as a record of what was explained, shared and left open. The agency retains its authorization decision; a well-organized handoff supports that decision without promising its outcome. ### Choosing a FedRAMP 20x Assessor Who Can Review Your Automation - URL: https://boundera.io/blog/20x/fedramp-20x-assessor-automation-expertise - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:17:17.162373+00:00 - Updated: 2026-10-10T23:18:32Z - Reading time: 3 minutes - Main question: How can a Class B or C provider assess an independent assessor's ability to review its automation? - TL;DR: Start with recognized assessors, then test the proposed team's fit through a sanitized validation-code walkthrough and relevant experience. FedRAMP describes recognition as a minimum bar and recommends checking automated-validation code review skills. The demonstration questions here are buyer advice. - Excerpt: Evaluate the proposed assessor team with a practical automated-validation walkthrough, platform questions and a clear staffing and review scope. Assessing FedRAMP 20x assessor automation expertise takes more than asking whether a firm has cloud experience. Put a representative automated validation in front of the people proposed for your engagement and ask them to explain what the code proves, what it misses and how they would investigate a misleading result. This is buyer diligence advice for a Class B or C provider choosing an independent assessor. It builds on FedRAMP's own guidance to check platform knowledge, deployment expertise and the ability to review automated validation code. ## Start with recognition, then investigate fit FedRAMP's assessor-selection guidance says partnering with a FedRAMP Recognized independent assessment service is mandatory for providers seeking Class B, C or D certification. The Marketplace identifies recognized assessors, but a listing is not FedRAMP endorsement of a business. The same guidance describes recognition and related A2LA certification requirements as a minimum bar, warning that technical expertise and familiarity with recent changes vary. [FedRAMP Finding an Assessor](https://www.fedramp.gov/2026/providers/implement/assessor) The official guidance recommends checking the personnel's understanding of Rev5 versus 20x, certification classes, relevant platforms, third-party services, deployment models and code review of automated validations. Use those questions to move beyond the firm's general qualifications to the team that will perform your work. ## Walk through one validation from input to conclusion Choose a sanitized example from your evidence process. Give candidates enough context to understand the intended assertion, the resources in scope and the output. The following demonstration prompts are an editorial procurement exercise, not extra recognition requirements: - Which source data supports the conclusion, and how would you check its completeness? - What happens if the query returns an empty result or loses access to a resource? - How would you distinguish a current observation from stale evidence? - Which code paths produce failure, uncertainty or a successful result? - What would you inspect to decide whether the assertion covers the intended scope? Look for a concrete reasoning process. A useful discussion might identify an ambiguous success condition, request additional context and explain how the assessor would resolve it. The objective is to understand the proposed team's review method, not to obtain an assessment conclusion during a sales call. Our [telemetry and AI summaries article](/blog/20x/fedramp-20x-deterministic-telemetry-ai-summaries) offers a related distinction between measured evidence and the prose used to explain it. ## Confirm experience and the actual staffing plan FedRAMP's guidance recommends examining prior certification paths and classes assessed, Rev5 or 20x assessment experience, engagement with program updates and past customer experience. It also encourages comparing proposals from multiple recognized assessors. [FedRAMP assessor-selection guidance](https://www.fedramp.gov/2026/providers/implement/assessor) For your comparison, ask who will review the code, who understands your deployment model and how substitutions will be handled. Request a sanitized example of a finding and its explanation. Ask references about the clarity of technical discussions and the usefulness of findings, rather than only whether a project reached its desired outcome. If the engagement includes advisory work, describe that scope separately from independent assessment and obtain an explanation of the applicable independence arrangements. The [advisor-listing guide](/blog/20x/fedramp-20x-advisor-marketplace-listing-meaning) explains why advisory listings convey different information from assessor recognition. ## Compare the proposed work, not a promised outcome Create a short comparison record covering named personnel, demonstrated technical fit, review approach, deliverables, access needs, communication and pricing assumptions. These are suggested purchasing criteria. Before selecting a team, resolve unclear boundaries: which automation will be examined, what evidence the provider will supply, and how technical disagreements will be documented. A strong proposal explains the scope and approach clearly without turning a sales promise into an assessment conclusion. ### Preparing for the FedRAMP 20x Review-Team Deep Dive - URL: https://boundera.io/blog/20x/fedramp-20x-review-team-deep-dive - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:13:51.003293+00:00 - Updated: 2026-10-10T23:16:58Z - Reading time: 3 minutes - Main question: How should a provider prepare for the likely FedRAMP 20x review-team Deep Dive? - TL;DR: Rehearse the submitted access path and prepare owners to explain the Certification Package Overview and Security Decision Record. FedRAMP describes the Deep Dive as likely. Its 30-day initial-decision target is an internal goal, not an SLA, and pauses while it waits for the provider. - Excerpt: Prepare working package access, decision explanations and request owners for the likely 20x Deep Dive, while treating the 30-day goal accurately. Prepare for a FedRAMP 20x review team deep dive by making the package easy to access and the decisions easy to explain. The most useful preparation is a working route from the Certification Package Overview to the Security Decision Record and the people who understand the evidence. FedRAMP's published guidance says the Review Team will likely schedule a Deep Dive for 20x. Keep that qualifier: the guidance describes a likely part of the review process, not an identical meeting promised for every application. [FedRAMP Getting Certified](https://www.fedramp.gov/2026/providers/implement/get-certified) ## Understand the review sequence and the clock The guidance describes an early completeness scan, assignment of a Review Team, access requests through the submitted trust-center process, and review of the Certification Package Overview. For 20x, the likely Deep Dive covers the overall approach, the overview and the Security Decision Record. The same page states an internal goal of making an initial decision within 30 days of receiving an application. It expressly says there is no review SLA. Time stops counting when FedRAMP cannot move forward because it is waiting for the provider. Do not convert that initial-decision target into a guaranteed certification date. [FedRAMP review-process guidance](https://www.fedramp.gov/2026/providers/implement/get-certified) For planning, distinguish your own response time from the review team's processing time. Track open requests and when a complete response was supplied, without assuming that your internal tracker determines FedRAMP's official clock. ## Rehearse the package through the reviewer's access path Use the access instructions you submitted to rehearse retrieval of the materials. The following is an internal preparation exercise, not an official checklist: 1. Have someone outside the package-authoring team follow the instructions. 2. Confirm they can find the current overview and Security Decision Record. 3. Follow several evidence references from a decision to the underlying material. 4. Check that the people responsible for resolving access problems know how to respond. 5. Record broken links, confusing version labels and unexplained access restrictions for correction. Our [trust-center scope guide](/blog/20x/fedramp-20x-trust-center-agency-scope) addresses the surrounding sharing responsibilities. The rehearsal here focuses on the route a reviewer will actually use. ## Prepare owners to explain decisions Invite the people who can explain the architecture, evidence generation and decision rationale to your internal rehearsal. Ask each owner to demonstrate one decision without relying on a slide that simply repeats its conclusion. Useful rehearsal questions include: Which service and configuration does this decision cover? What evidence supports it? How do you know that evidence is current? What uncertainty remains? Who can explain a failed validation or a change in the decision? These are suggested discussion prompts, not additional FedRAMP rules. The [recommended-rule decision guide](/blog/20x/fedramp-20x-recommended-rule-decisions) can help prepare explanations where the Security Decision Record documents a decision about a recommendation. ## Manage requests as review work FedRAMP's guidance says reviewers may request changes or issue an initial rejection when they find significant problems. It also says FedRAMP generally does not regularly follow up after requesting something from an applicant, and encourages attention to email and timely responses. [FedRAMP Getting Certified](https://www.fedramp.gov/2026/providers/implement/get-certified) Assign an internal owner to each request, preserve the original wording, identify the affected package version and assemble a response that points to the changed material. If several specialists contribute, have one person check that the answer is complete and consistent before sending it. The outcome of preparation should be practical: working access, understandable decisions and an accountable response process. Those are things your team can improve directly while the application moves through review. ### Hiring FedRAMP 20x Help: What an Advisor Marketplace Listing Proves - URL: https://boundera.io/blog/20x/fedramp-20x-advisor-marketplace-listing-meaning - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:12:37.396417+00:00 - Updated: 2026-10-10T23:14:57Z - Reading time: 3 minutes - Main question: What does an advisor Marketplace listing establish when buying FedRAMP 20x preparation support? - TL;DR: FedRAMP does not certify, vet or endorse advisory services. Advisor listing rules cover public service information and official-request responsiveness. Assess relevant experience, proposed personnel and work samples separately, and distinguish advisory work from recognized independent assessment. - Excerpt: Use an advisor Marketplace listing as a starting point for diligence, then check the proposed team, work samples and engagement scope. A FedRAMP 20x advisor Marketplace listing can help you find a service and its contact information. It does not establish that FedRAMP has evaluated the advisor's technical work or endorsed its ability to prepare your offering. Make the hiring decision around the people, scope and evidence of relevant work. For a provider comparing preparation support, the listing is a starting point for diligence. The useful next step is to ask what the proposed team can demonstrate about your architecture and the current 20x rules. ## What the official advisor guidance says FedRAMP describes advisory services as optional. Its guidance says FedRAMP does not certify, review, recommend or officially recognize them, and that Marketplace advisory listings are not vetted or endorsed by FedRAMP. An advisor can seek listing by meeting the published requirements. [FedRAMP Advisory Service Responsibilities](https://www.fedramp.gov/2026/responsibilities/advisors) That distinction matters when interpreting a sales presentation. Ask an advisor using a certification-style badge to identify precisely what it represents and who issued it. Do not treat the Marketplace listing itself as evidence that FedRAMP approved the advisor's methodology. ## What information sits behind a listing MKT-CAS-WEB requires advisors to publish consistent human-readable and machine-readable information on an appropriate website: a general service description, contact information and the types of consulting or advisory services offered. Positive customer attestations or references are optional in that rule. MKT-CAS-LRQ requires completion of the listing request form. [FedRAMP Advisor Marketplace Listing rules](https://www.fedramp.gov/2026/advisors/rules/marketplace-listing) MKT-CAS-RFR also requires replies within five business days to requests from @fedramp.gov or @gsa.gov sent to the listed contact information. This is a response obligation to those official requests; it is not a promised response time for your commercial engagement. Use the public description to establish what the organization offers, then confirm the proposed scope directly. A listing that describes general consulting does not tell you which named engineer will review your evidence pipeline or maintain your rule mappings. ## Ask for a concrete demonstration of fit The following are buyer diligence suggestions, not additional Marketplace eligibility rules: 1. Share a sanitized description of your service and ask the proposed team to identify the preparation questions it would investigate first. 2. Ask for a work sample showing how an official source was translated into a documented decision and supporting evidence. 3. Ask how the team tracks source changes and corrects advice when applicability or wording changes. 4. Request references relevant to the actual type of work you are purchasing, even though references are optional under the listing rule. 5. Put deliverables, ownership, review rounds and handoff expectations in the engagement scope. For example, a package-readiness engagement could demonstrate how it connects a decision to evidence using the [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist). Evaluate the quality of the explanation and the work product rather than the confidence of the sales promise. ## Keep advisory work and independent assessment distinct FedRAMP's assessor guidance says Class B, C and D providers must partner with a FedRAMP Recognized independent assessment service. Those assessor listings follow a formal recognition process, while still not representing FedRAMP endorsement of a business. The guidance describes recognition as a minimum bar and advises checking expertise and experience. [FedRAMP Finding an Assessor](https://www.fedramp.gov/2026/providers/implement/assessor) Name the advisory and assessment responsibilities separately in your procurement plan. If a proposal combines services, obtain a clear account of the roles and applicable independence arrangements before relying on it. This is a scoping practice, not a new waiting period or recognition rule. Choose the advisor whose proposed team can explain the work you need, show relevant evidence and leave your team able to operate the resulting process. Keep that decision separate from the presence of a Marketplace entry. ### FedRAMP 20x Mitigation vs. Remediation: Keep Vulnerability Status Accurate - URL: https://boundera.io/blog/20x/fedramp-20x-mitigation-versus-remediation-status - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:11:25.277420+00:00 - Updated: 2026-10-10T23:13:05Z - Reading time: 3 minutes - Main question: How should Class B and C teams distinguish mitigation from remediation in vulnerability records? - TL;DR: Mitigation reduces risk and impact; a fully mitigated weakness still exists. Remediation eliminates or neutralizes the weakness so it is no longer detected. Record treatment evidence separately from task closure, and preserve the KEV remediation recommendation even after full mitigation. - Excerpt: Keep Class B and C vulnerability status tied to the remaining weakness and treatment evidence, even when an engineering task is complete. A security ticket can be complete while the weakness it addresses still exists. For Class B and C teams, understanding FedRAMP 20x mitigation vs remediation prevents a completed mitigation task from turning into an inaccurate claim that a vulnerability has disappeared. Use separate descriptions for the weakness, the treatment applied and the evidence supporting its present state. That gives engineers and reviewers a clearer answer than a single closed-ticket label. ## Distinguish reduced risk from removal of the weakness The official VDR guidance distinguishes mitigation, which reduces vulnerability risk and impact, from remediation, which entirely eliminates the vulnerability. It explicitly says a fully mitigated vulnerability still exists with negligible risk until remediated. If full mitigation or remediation is not possible, the guidance recommends partial mitigation promptly, progressively and persistently. [FedRAMP Vulnerability Detection and Response](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-detection-and-response) FedRAMP's definition of a remediated vulnerability describes a weakness that has been eliminated or neutralized and is no longer detected. Use the official definitions when assigning the status, rather than treating all successful work as remediation. [FedRAMP Definitions](https://www.fedramp.gov/2026/definitions/#remediated-vulnerability) For example, restricting an exposure path may support a mitigation decision. Whether the weakness has actually been remediated is a separate question requiring evidence about that weakness. This example illustrates the distinction; it does not establish that any particular network restriction fully mitigates a vulnerability. ## Record what changed and what remains For the Class B and C scope discussed here, VDR-CSO-RES requires providers to systematically, persistently and promptly manage all detected vulnerabilities, including tracking, evaluation, monitoring, mitigation, remediation, exploitation assessment and reporting. [FedRAMP VDR rules](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-detection-and-response) A useful internal working record can separate these editorial fields: - The affected resource and the weakness being evaluated. - The treatment performed, with links to change evidence. - The remaining weakness and the reasoning behind the selected status. - Verification results, evaluation date and responsible owner. - Conditions that would invalidate the mitigation or reopen engineering work. These are suggested working fields, not a replacement for the applicable reporting schema. Keep your operational task state separate from the vulnerability state so a dashboard can show that a change is complete while further remediation work remains. ## Keep KEV remediation visible after mitigation VDR-TFR-KEV uses SHOULD for remediation of Known Exploited Vulnerabilities according to the due dates in CISA's KEV Catalog, even when a vulnerability is fully mitigated, referring to BOD 26-04 or successor CISA guidance. Preserve both the recommendation's force and the parenthetical about full mitigation when designing your queue. [FedRAMP VDR rules](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-detection-and-response) As a practical queue design, keep the applicable catalog date visible beside the treatment state and source reference. Do not have a workflow silently erase that date when a mitigation task closes. Review the governing rule and current catalog entry when making the decision. The VDR page lists December 7, 2026 for initial and ongoing certification adoption, with a grace-period end of March 7, 2027; optional adoption starts July 4, 2026. Those dates belong in the applicability assessment for this guidance. ## Test status changes against the underlying evidence Take a sample of recently closed engineering tickets and ask what the corresponding vulnerability record now asserts. Can the owner explain the treatment, the remaining weakness and the evidence for the status without relying on the word closed? For detection coverage, use the [vulnerability sampling guide](/blog/20x/fedramp-20x-vulnerability-sampling-coverage-plan). For evidence organization, use the [readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist). Keep the review centered on the actual state of the weakness and the support for the decision. ### FedRAMP 20x Package Sharing: Remove Sensitive Details Without Hiding Risk - URL: https://boundera.io/blog/20x/fedramp-20x-package-sharing-sensitive-details - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:09:58.427021+00:00 - Updated: 2026-10-10T23:11:47Z - Reading time: 3 minutes - Main question: How should Class B and C providers remove sensitive package details without hiding risk? - TL;DR: CDS-CSO-RIS requires decision-useful certification data and recommends excluding compromise-enabling sensitive details. Preserve accurate risk information when abstracting specifics. Review necessary-party access and conditional public sharing as separate decisions. - Excerpt: Review Class B and C certification data for compromise-enabling details while preserving the accurate risk information agencies need. An agency needs enough detail to understand risk. It does not need a usable credential copied into a package. For Class B and C providers handling FedRAMP 20x sensitive certification data, the practical task is to preserve the risk explanation while removing details that could help someone compromise the offering. Treat each edit as an information-design decision: what does the recipient need to evaluate, and what unnecessary operational detail can be abstracted? A vague assurance that everything is secure is not a useful replacement for the underlying risk. ## Keep the risk while abstracting dangerous specifics CDS-CSO-RIS requires sufficient information in certification data to support agency authorization decisions. It also says providers SHOULD NOT include sensitive information likely to enable unauthorized access, harm, disruption or another adverse impact. Its note explicitly says this does not permit exclusion of accurate risk information; specifics likely to lead to compromise should be abstracted. [FedRAMP Certification Data Sharing](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing) The official guidance identifies credentials, excessive methodology detail exposing weaknesses, and employee personal information as things to examine. Use that guidance to review both prose and attachments: screenshots, command output and exported configuration can carry details that the narrative author did not intend to share. This article addresses Class B and C provider rules. The CDS page lists July 4, 2026 for initial certification, January 1, 2027 for ongoing certification, and a grace period ending on the first independent assessment started after January 1, 2027. ## Use a two-part review for each proposed edit First, identify the disclosure concern. Second, test whether the replacement still lets the recipient understand the relevant risk. The examples below are editorial suggestions for that review, not official replacement language. | Material being reviewed | Safer description to consider | Information to preserve | | --- | --- | --- | | A procedure containing a recovery credential | Describe the controlled recovery mechanism and its governance without the credential value | Who can use the mechanism, under what conditions, and how its use is controlled | | A diagram with an exploitable operational detail | Abstract the sensitive detail while explaining the affected component and dependency | Scope, exposure and the actual weakness or limitation | | An evidence export containing unnecessary employee details | Use a role or consistent reference where that supports the decision | Accountability, relevant action and evidence provenance | Do not let the replacement turn a known weakness into an unqualified claim that the control works. Where an abstraction makes the risk hard to understand, revise the explanation and consult the appropriate information owner. ## Separate necessary access from optional public sharing CDS-TRC-USH requires trust centers to share certification data with all necessary parties without interruption. Separately, CDS-CSO-RPS permits providers to share some or all package information publicly or with other parties if the provider determines doing so will not likely adversely affect the offering. That conditional permission is a different decision from giving necessary parties access. [FedRAMP Certification Data Sharing](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing) Use separate review records for the intended recipients and for any public release. Removing a credential from a document does not, by itself, establish the determination needed for public sharing. Our [trust-center scope article](/blog/20x/fedramp-20x-trust-center-agency-scope) provides the broader agency-access context. ## Preserve a traceable editing decision For your internal workflow, record the document version, the sensitive detail identified, the replacement explanation, the reviewer and the intended audience. This is an editorial tracking suggestion. Keep the restricted original under your own appropriate access controls when needed to explain the edit. Before release, have a second reader explain the risk back using only the shared version. If they cannot tell what is affected or what uncertainty remains, the abstraction has removed too much. Pair that check with the [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) so the shared explanation still points to usable evidence. ### FedRAMP 20x Vulnerability Sampling: Building a Defensible Coverage Plan - URL: https://boundera.io/blog/20x/fedramp-20x-vulnerability-sampling-coverage-plan - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:08:44.661512+00:00 - Updated: 2026-10-10T23:10:31Z - Reading time: 3 minutes - Main question: How can Class B and C teams build a defensible FedRAMP 20x vulnerability sampling plan? - TL;DR: Sampling effectively identical resources is permitted unless it reduces detection efficiency or effectiveness. Record why the sample represents the group and revisit that decision after changes. Keep recommended sample detection separate from mandatory machine verification and validation, even where their timeframes match. - Excerpt: Build a Class B and C sampling plan around effectively identical resources, detection effectiveness, change handling and the distinct verification duty. FedRAMP 20x vulnerability sampling starts with a coverage question: why does the selected resource represent the others? A fleet sharing a deployment name can still contain different software, configuration or exposure. For Class B and C teams, a useful plan explains the grouping, records the evidence and reconsiders the group when those assumptions change. The plan below is an implementation approach. The official rules define when sampling is permitted and distinguish recommended sample detection from mandatory machine verification and validation. ## Preserve the condition attached to sampling VDR-CSO-SIR permits sampling effectively identical information resources, especially machine-based resources, for vulnerability detection unless doing so would decrease detection efficiency or effectiveness. VDR-CSO-DAC separately recommends automatic vulnerability detection on representative samples of new or significantly changed resources. These are MAY and SHOULD provisions respectively. [FedRAMP Vulnerability Detection and Response](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-detection-and-response) Do not turn the permission into a fleet-wide assumption. As an engineering practice, write down the characteristics used to establish effective identity: deployed artifact, relevant configuration, enabled components and exposure conditions. Decide how drift would be detected and which differences would cause a resource to leave the group. These suggested criteria are not an official percentage or sample-size formula. For example, replicas deployed from one image may look like one group. A replica with an additional plugin or different network exposure deserves a fresh grouping decision. The practical question is whether the selected sample still represents what the detection process needs to find. ## Separate three decisions in the coverage plan Keep the permission to sample, the detection cadence and the verification obligation visible as separate decisions. For the Class B and C scope addressed here, the official page specifies: | Provision | Class B | Class C | | --- | --- | --- | | VDR-TFR-PSD: persistent detection on representative samples of similar machine-based resources | SHOULD, at least every 7 days | SHOULD, at least every 3 days | | VDR-TFR-MVX: verify and validate machine-based resource status | MUST, at least every 7 days | MUST, at least every 3 days | Matching timeframes do not make these the same activity or give both rules the same force. The [recommended-rule decision guide](/blog/20x/fedramp-20x-recommended-rule-decisions) explains how to handle the documentation implications of recommendations. The VDR page lists optional adoption from July 4, 2026, initial and ongoing certification adoption on December 7, 2026, and a grace-period end of March 7, 2027. Plan against these dates and the applicable class, rather than treating a page-format update as a new sampling policy. ## Make the coverage decision inspectable A compact working record can contain the following editorial fields: - Group identity and the inventory snapshot used to define membership. - Reasons the resources are effectively identical for detection purposes. - Selected resources, selection rationale and detection results. - Evidence that sampling does not reduce detection efficiency or effectiveness. - Changes or failures that trigger regrouping or broader detection. - Owner and date of the most recent coverage review. Link the record to the actual inventory and results instead of copying a stale resource count into a document. Retain enough context to explain a historical result after the fleet changes. ## Exercise changes and exceptions Try a controlled change to a resource characteristic used by the grouping logic. Check whether the process notices the difference, re-evaluates membership and schedules the appropriate detection work. Then test a failed or incomplete detection run: an attempted scan should not silently become a successful coverage result in your own reporting. Use the [evidence readiness checklist](/blog/20x/fedramp-20x-evidence-readiness-checklist) to connect these decisions to retrievable evidence. A defensible coverage plan lets another engineer reproduce why the group was selected, what was checked and when the assumptions stopped holding. ### FedRAMP 20x Availability Reporting During an Outage - URL: https://boundera.io/blog/20x/fedramp-20x-availability-reporting-during-outages - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:07:31.999578+00:00 - Updated: 2026-10-10T23:10:09Z - Reading time: 3 minutes - Main question: How should Class B and C providers keep FedRAMP 20x availability reporting accessible during an outage? - TL;DR: CDS-CSO-AVR requires Class B and C availability reporting to remain available when the primary offering is unavailable. Cover current status and at least 30 days of history, including incidents, in human-readable and machine-readable formats. Test shared dependencies and evaluate incident reportability separately. - Excerpt: Plan Class B and C availability reporting that necessary parties can reach during an outage, with current status, history and machine-readable access. When the application is down, its status page becomes one of the most useful services you operate. FedRAMP 20x availability reporting for Class B and C providers calls for more than a green indicator embedded in the application: the reporting service must remain available when the primary offering is unavailable. Design the reporting path around that failure condition. This article separates the official reporting rule from practical architecture and exercise suggestions. ## What the availability rule covers Under CDS-CSO-AVR, Class B and C providers MUST maintain a web service available to all necessary parties that shows current and historical core-service availability over at least the past 30 days, including availability incidents. Both human-readable and machine-readable formats are required. The service MUST remain available even when the primary cloud service offering is unavailable. The rule expressly permits this service to be separate from the trust center. Class A uses SHOULD instead of MUST for this rule. [FedRAMP Certification Data Sharing](https://www.fedramp.gov/2026/reference/certification-data-sharing) The page lists July 4, 2026 for obtaining initial certification and January 1, 2027 for maintaining ongoing certification, with the grace period ending on the first independent assessment started after January 1, 2027. Keep the applicable adoption timing alongside your design decisions. ## Trace the reporting service's failure dependencies Start with an architecture review of the status page, its data feed and the process used to update it. The following are implementation suggestions, not a mandated hosting pattern: - Identify shared DNS, identity, network and deployment dependencies with the primary offering. - Check whether operators can post an update if the ordinary administration console is unavailable. - Exercise both the page a person reads and the endpoint an agency tool consumes. - Confirm the historical incident record remains accessible during the simulated outage. - Record who owns recovery of the reporting service itself. Independent hosting can help isolate some failures, but the useful test is the actual dependency path. A separate hostname can still depend on the same identity provider or deployment pipeline. Describe which failure your design tolerates and which dependencies remain shared. ## Keep current state and history understandable Use consistent service names across the human view and machine feed. For example, distinguish an unavailable administrative console from delayed background processing rather than collapsing both into one unexplained status value. This is editorial design advice; the official rule supplies the coverage and availability obligations. For an exercise, choose a recent incident and ask a reader to reconstruct what happened using the reporting service alone. Can they identify the affected core service, the period of disruption and its current state? Then perform the same exercise against the machine-readable output. Investigate mismatches before relying on either view during a real outage. Our [trust-center scope guide](/blog/20x/fedramp-20x-trust-center-agency-scope) covers the broader information-sharing context. Keep the outage-reporting test focused on whether necessary parties can actually obtain availability information. ## Evaluate incident reportability separately For the Class B and C scope discussed here, IEC-CSO-EFR requires prompt evaluation of whether an incident affects, or is likely to affect, the confidentiality or integrity of federal customer data. Incidents meeting that test are FedRAMP Reportable Incidents and follow the Incident Evaluation and Communication rules. [FedRAMP Incident Evaluation and Communication](https://www.fedramp.gov/2026/reference/incident-evaluation-and-communication) A status update alone does not answer that evaluation question. Route the operational outage and the security evaluation to named owners, and retain the reasoning connecting them. When the evaluation establishes reportability, use the [incident notification workflow](/blog/20x/fedramp-20x-incident-notification-workflow) for the communication process. The practical acceptance exercise is straightforward: interrupt the primary offering, retrieve the availability page and feed, inspect the retained history, and confirm that the team can still update the report. Save the results and resolve the dependencies the exercise exposes. ### FedRAMP 20x: Documenting Decisions About Recommended Rules - URL: https://boundera.io/blog/20x/fedramp-20x-recommended-rule-decisions - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:06:25.738413+00:00 - Updated: 2026-10-10T23:07:57Z - Reading time: 3 minutes - Main question: How should Class B and C providers document a decision about an applicable FedRAMP 20x recommendation? - TL;DR: Read the rule force and applicability first. Explain the decision and customer risk in the Security Decision Record, preserve senior-official acceptance where specified, and retain independent verification and validation. A MUST remains an absolute requirement. - Excerpt: Record Class B and C decisions about SHOULD rules with their circumstances, customer risk, senior-official acceptance where specified and independent review. A FedRAMP 20x recommendation needs a reasoned decision, not a blank row in the implementation tracker. For Class B and Class C teams, connect the rule's stated force to an explanation in the Security Decision Record, including what the decision means for customers. ## Read the rule force before deciding The official [guide to FedRAMP rules](https://www.fedramp.gov/2026/rules/) distinguishes MUST and MUST NOT as absolute requirements or prohibitions. SHOULD and SHOULD NOT allow valid reasons in particular circumstances, but require the implications to be understood and carefully weighed. Parties must explain their decisions about those recommended rules in security documentation. MAY is genuinely optional. Do not treat SHOULD as a synonym for irrelevant. First check that the rule applies to your class, path, and situation. Then document how you follow it or why your circumstances support a different decision. Keep an absolute requirement out of a process intended for recommendations. ## Put the rationale in the Security Decision Record [SDR-CSO-FRR](https://www.fedramp.gov/2026/providers/20x/rules/security-decision-record/#fedramp-rules) requires a human-readable and JSON Security Decision Record for applicable rules. It includes an explanation of implementation or the reason and resulting customer risk for not following the rule. Its verification and validation entries likewise address implementation or acceptance of the reason by a senior official. Independent verification, independent validation, responses to their comments, and applicable rule-specific artifacts are also included. A useful internal drafting outline is the rule identifier and version, the decision, relevant circumstances, customer effects, supporting evidence, and responsible official. Those fields are suggested working aids, not a replacement schema. Follow the official rule and schema when producing the actual record. For example, a decision about a recommended capability should explain the relevant product limitation and its customer effect. “Not implemented” alone gives a reviewer little to evaluate. Be specific about what exists today and what evidence supports the explanation. ## Preserve independent review of the decision Senior-official acceptance is one part of the rule's record; SDR-CSO-FRR also calls for independent verification and validation. Keep the independent comments and your responses connected to the same decision. Avoid rewriting a concern into an unconditional approval when preparing a cleaner presentation. Internal acceptance does not change MUST into SHOULD: the official rule-force guidance still defines MUST as absolute. Use a separate corrective-action discussion when the issue is failure to meet an absolute requirement rather than a justified choice about a recommendation. ## Keep the record current when circumstances change As an implementation practice, revisit the rationale after a product change, new evidence, or a changed customer use case. SDR-CSO-MTD requires the record's version, last-update date and time, and source of update. Maintain those metadata alongside the current decision. The 20x SDR page lists July 4, 2026 for initial certification, January 1, 2027 for ongoing certification, and grace ending at the first FedRAMP independent assessment started after January 1, 2027. Check your applicable adoption position. The aim is a decision another reviewer can follow, with its reasoning and evidence still attached. ### How to Ask FedRAMP for Clarification During 20x Preparation - URL: https://boundera.io/blog/20x/fedramp-20x-support-clarification-requests - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:01:50.795729+00:00 - Updated: 2026-10-10T23:06:52Z - Reading time: 3 minutes - Main question: How can a provider ask FedRAMP for clarification while preparing for 20x? - TL;DR: Start with current official documentation and a precise factual question. Use public discussion where appropriate; a provider-specific direct request should come from the provider. Check the live support contact and do not assume a guaranteed response time or private advisory service. - Excerpt: Check current documentation, isolate one factual ambiguity, choose the appropriate support route and preserve the answer in your implementation record. When a FedRAMP 20x rule is unclear, isolate the factual question before asking for help. “Which option should our company buy?” and “Does this rule apply to this described situation?” ask for different kinds of support. A focused request makes the unresolved point easier to see. The official [Getting Support page](https://www.fedramp.gov/2026/support/) describes documentation as the first line of support, public discussion as a preferred secondary route, and direct help when those resources do not answer the question. ## Check the current rule and its context Start with the exact rule identifier and current official text. Read its class, path, definitions, exceptions, and effective dates. Record the version you reviewed and the specific ambiguity left after reading the surrounding material. As a practical check, distinguish an old article, an RFC proposal, and the current rule. The support page points readers to official documentation and program updates; an unanswered question based on superseded wording may disappear when the current text is read. ## Choose a channel that fits the question FedRAMP's support guidance says it strongly prefers and prioritizes public questions so others can benefit. It points to the Community GitHub discussions and community events. For a general interpretation question that can be described publicly, start with that public context. For a provider-specific situation requiring direct help, the page says providers should contact FedRAMP themselves rather than using an intermediary. As checked on October 10, 2026, it identifies info@fedramp.gov as the interim contact while a transition to web-based support forms is planned. Verify the current page before sending; its preview of future forms is not evidence that those forms are already available. ## Write a concise clarification request Use this suggested outline: 1. Name the offering context and applicable certification class or path. 2. Link the exact rule and identify the unresolved sentence. 3. Describe the relevant facts without unnecessary customer or sensitive details. 4. Explain the two interpretations you cannot reconcile. 5. Ask one explicit factual clarification question. This outline is editorial guidance, not an official form. For example, ask whether a stated condition applies to the described resource rather than asking FedRAMP to design the architecture for you. Keep commercial advice and procurement choices outside the clarification request. The support page warns that communications with FedRAMP are federal records that may be disclosed. Review the material you include accordingly. It also says FedRAMP does not provide a response-time SLA or guarantee and may ignore inappropriate requests or questions already addressed publicly. ## Route other work through its proper process The support guidance says FedRAMP will not provide private business advice or mediate disputes between providers and their assessors or advisors. Its meeting limits include narrow mission-critical exceptions; do not turn a clarification request into an expectation of a private consultation. Use the specific official process for incident notifications or formal RFC comments rather than treating a general support request as a substitute. Our [public-comment workflow](/blog/20x/fedramp-20x-rfc-public-comment-workflow) explains how to prepare focused feedback on proposals. After receiving clarification, link it to the internal question and check whether the official documentation changes. Record any remaining uncertainty explicitly. That leaves the team with a traceable interpretation instead of an unattributed statement passed from one planning document to another. ### FedRAMP 20x Collaborative Monitoring: Agency Roles and Provider Responsibilities - URL: https://boundera.io/blog/20x/fedramp-20x-collaborative-monitoring-agency-roles - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:01:31.663419+00:00 - Updated: 2026-10-10T23:06:02Z - Reading time: 3 minutes - Main question: How should Class B and C providers organize FedRAMP 20x collaborative monitoring with agencies? - TL;DR: The provider supplies the three-month report, next target date, asynchronous feedback mechanism and desensitized feedback summary. Synchronous Quarterly Reviews are SHOULD for Class B and MUST for Class C. Agencies retain their own risk decisions, and adoption dates matter. - Excerpt: Assign Class B and C ownership for reports, asynchronous agency questions and shared feedback, while keeping Quarterly Review duties distinct. For a FedRAMP 20x Class B or C provider, collaborative monitoring needs an operating process for reports, questions, and follow-through. Assign those jobs explicitly instead of assuming a familiar agency contact will coordinate everything after certification. FedRAMP's [agency sponsorship guidance](https://www.fedramp.gov/2026/agencies/sponsoring/ongoing/) says sponsorship responsibilities end when the offering receives certification and the former sponsor has no special ongoing duties. For teams carrying sponsor-centered practices forward, that is useful transition context. The current [Collaborative Continuous Monitoring rules](https://www.fedramp.gov/2026/providers/20x/rules/collaborative-continuous-monitoring/) specify the provider's reporting and review responsibilities. ## Own the report and its next date CCM-OCR-AVL requires an Ongoing Certification Report every three months for all necessary parties, covering the whole period since the previous summary in a consistent human-readable format. Its listed high-level contents apply where relevant, including certification-data changes, planned changes, accepted vulnerabilities, transformative changes, updated recommendations, direct agency users, reportable incidents or a no-incident attestation, and incident lessons where applicable. CCM-OCR-NRD separately requires the next report's target date with public Certification Data. As a practical ownership model, assign one person to coordinate the release, with contributing owners for the underlying operational records. Keep the report date and preparation tasks visible to the team. ## Give agencies an asynchronous way to ask questions CCM-OCR-FBM requires an asynchronous feedback and question mechanism for every report. Its note allows email as a default while encouraging more interactive approaches where appropriate. CCM-OCR-AFS requires an anonymized and desensitized summary of questions, feedback, and answers, either as an addendum or in the next report. Set up a suggested internal handoff: receive the question, identify its technical owner, respond, and decide how to include the desensitized answer in the shared summary. Avoid copying identifying or sensitive details into a broadly shared digest. CCM-OCR-LSI prohibits irresponsible disclosure of sensitive report information likely to adversely affect the offering. ## Keep the report separate from the meeting The synchronous Quarterly Review has a class-specific obligation. CCM-QTR-MTG says Class B providers SHOULD host one every three months; Class C providers MUST. The review is open to all necessary parties and concerns aspects of the latest report the provider determines are most relevant to agencies. A completed report does not describe whether a meeting was held, and a meeting invitation does not demonstrate that the report was supplied. Track those activities separately. For a review you hold, prepare focused discussion topics from the report and unresolved questions rather than reading the document aloud. The CCM overview describes shared information supporting each agency's own risk-based decisions about ongoing authorization. Plan for agency questions without treating a shared provider meeting as a replacement for those decisions. ## Apply the adoption dates to the operating plan The cited 20x CCM page lists July 4, 2026 for obtaining initial certification, January 1, 2027 for maintaining ongoing certification, and grace ending at the first FedRAMP independent assessment started after January 1, 2027. Use the applicable position when deciding which tasks are due. As an implementation practice, run a rehearsal covering the report release, published next date, question intake, desensitized summary, and applicable review meeting. Record who owns each handoff. That gives the team a repeatable process while preserving the distinction between its own workflow choices and the official obligations. ### How to Submit Useful Public Comments on FedRAMP 20x Proposals - URL: https://boundera.io/blog/20x/fedramp-20x-rfc-public-comment-workflow - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T23:00:18.594756+00:00 - Updated: 2026-10-10T23:02:01Z - Reading time: 3 minutes - Main question: How can engineering and GRC teams prepare useful public comments on FedRAMP 20x RFCs? - TL;DR: Check the current RFC's instructions and deadline, submit separate comments on specific issues early, and explain the operational effect and proposed change. Track published outcomes rather than treating a proposal or your comment as an effective rule. - Excerpt: Turn a specific implementation concern into early, focused RFC feedback, then track the published outcome into your work plan. An implementation concern becomes easier to evaluate when it names the proposed text, describes the concrete effect, and offers a specific change. Use that structure when commenting on a FedRAMP 20x proposal instead of waiting to assemble a broad position paper. FedRAMP's [NTC-0011 public-comment retrospective](https://www.fedramp.gov/notices/0011/) explains its preference for early, separate comments on specific issues. The workflow below turns that preference into a practical internal process. It is suggested writing guidance, not an official submission template. ## Identify the proposal and its current window Open the specific RFC and record its identifier, section, current wording, submission instructions, and closing date. Check those details on the current RFC page when submitting. A date or channel copied from an older notice may not describe the current opportunity. NTC-0011 describes RFCs as a way to test potential changes before decisions are finalized. Track a proposed rule separately from an effective requirement in your implementation backlog. The notice also describes GitHub as the primary public interaction mechanism and a planned public-form option; verify the actual current options for the RFC rather than assuming every announced process change is already available. ## Write one comment around one concrete problem A useful internal outline is: - **Reference:** the exact proposal section and wording at issue. - **Effect:** what a team would have to do and where the ambiguity or burden arises. - **Example:** a short, non-sensitive scenario that demonstrates the issue. - **Change:** specific wording or a focused question that would resolve it. - **Reason:** how the suggested change preserves the proposal's intended outcome. For example, if a proposed timing rule leaves the start event unclear, describe two plausible interpretations and the operational difference between them. Ask for the start event to be specified. Avoid introducing a claim that either interpretation is already the rule. Keep unrelated issues in separate comments. NTC-0011 says FedRAMP prefers early, frequent partial feedback over large consolidated submissions at the end of the window. Submit a clear issue when it is ready rather than holding it for every department's final opinion. ## Review the comment before sending it Have the relevant technical owner check that the example reflects real operations. Remove unnecessary customer details and confirm that the suggested change answers the identified problem. These are your editorial checks; they do not imply a guaranteed response or adoption of the suggestion. Use the RFC's current submission mechanism and retain the public comment reference in your internal tracker. This article explains preparation; it does not submit a comment on your behalf. ## Follow the outcome into the rules NTC-0011 explains that initial outcomes summarize comment themes and their effect on the result. It explicitly says a formal comment-by-comment disposition is not part of the process. Look for the relevant theme and resulting wording instead of expecting an individual response for every sentence. When an outcome or final rule appears, update the implementation task with the adopted text and applicable dates. Keep the original concern linked for context, but let the published result drive subsequent work. NTC-0011 describes public comments as feedback on potential guidance changes before decisions are finalized. ### FedRAMP 20x Trust Center Scope: Agency Access and Provider Dependencies - URL: https://boundera.io/blog/20x/fedramp-20x-trust-center-agency-scope - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T22:58:50.908198+00:00 - Updated: 2026-10-10T23:01:19Z - Reading time: 3 minutes - Main question: How do agency-use scope and a FedRAMP 20x provider's trust-center dependency analysis differ? - TL;DR: The official commercial trust-center example is out of scope for the described agency use, but explicitly preserves a possible provider-side assessment dependency. Agencies decide their use-case scope; Class B and C providers separately apply the relevant Minimum Assessment Scope rules. - Excerpt: Separate the agency's use of a commercial trust center from a Class B or C provider's assessment-boundary analysis of its dependency. When a FedRAMP 20x provider evaluates a trust center, two scope questions can sound deceptively similar. Is the agency's use of the trust center within FedRAMP's scope? And does the provider's use of that service belong in the provider's own assessment boundary? Answer them separately. ## Read the agency-use example with its conditions The official [Scope of FedRAMP guidance](https://www.fedramp.gov/2026/scope/) gives an example in which an agency visits a commercial trust center to collect security information and assess a cloud service's risk posture. The example says this use is outside FedRAMP's scope from the agency customer's perspective because the trust center is not collecting federal information in that particular use case. The guidance also says only an agency can determine whether its use case is in scope. It does not provide a blanket list of services that are always exempt. The commercial trust-center example therefore does not decide every deployment or every agency workflow bearing that label. ## Keep the provider-side caveat attached The same example explicitly cautions that the provider's use of the trust center might be included in that cloud service's Minimum Assessment Scope and could require authorization as a result. The agency-use conclusion does not erase the provider-side dependency question. For Class B and Class C providers, [MAS-CSO-IIR](https://www.fedramp.gov/2026/providers/20x/rules/minimum-assessment-scope/#identify-information-resources) requires identifying resources likely to handle federal customer data or affect its confidentiality, integrity, or availability. MAS-CSO-TPR addresses applicable third-party resources only when the IIR condition applies. It calls for documentation of usage and configuration, justification, mitigation measures, and compensating controls. Use those applicable rules to evaluate the real dependency. Do not infer either that every trust center needs separate certification or that no trust center can affect your boundary. ## Describe the actual flows before selecting a conclusion A practical internal review can record: - What information the provider publishes or stores in the trust center. - What information agency users supply, if any. - How the service connects to the offering and supporting systems. - Which party controls access and administration. - Which use-case assumptions the scope analysis depends on. These are suggested analysis prompts, not a FedRAMP-prescribed questionnaire. If the planned use changes, revisit the assumptions rather than carrying forward a conclusion from an earlier, narrower workflow. For example, viewing a provider's commercial security materials and operating a tenant that stores agency-specific sensitive information are different factual descriptions. Give the agency an accurate account of the proposed use so it can make its determination, and separately document your provider dependency analysis. ## Record two decisions, not one marketing label Keep the agency-use question and the provider assessment-boundary question distinct in procurement notes and architecture reviews. Attach the official example's caveat wherever its out-of-scope conclusion is summarized. The useful output is a traceable explanation of the actual data and responsibilities. A trust-center label alone is too little information to carry either scope decision. Recheck the current official guidance and applicable provider rules when the service or use case changes. ### FedRAMP 20x Deterministic Telemetry: Where AI Summaries Fit - URL: https://boundera.io/blog/20x/fedramp-20x-deterministic-telemetry-ai-summaries - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T22:56:21.295266+00:00 - Updated: 2026-10-10T22:58:07Z - Reading time: 3 minutes - Main question: How should teams distinguish FedRAMP 20x deterministic telemetry from AI-generated summaries? - TL;DR: FRD-DTM defines deterministic telemetry as direct, verifiable and reproducible system observations. It excludes generative and predictive output as the factual system-state record. Preserve original observations and treat summaries as separate interpretations in your workflow. - Excerpt: Keep authoritative system observations separate from generated explanations, and test that boundary when evaluating evidence tooling. When evaluating an evidence platform, ask to see the observation behind the explanation. A generated summary may help a reader navigate records, but it should not become the only surviving account of what a system actually did. FedRAMP 20x's definition of deterministic telemetry makes that boundary concrete. ## Start with the authoritative observation The official [Deterministic Telemetry definition, FRD-DTM](https://www.fedramp.gov/2026/definitions/#deterministic-telemetry), describes verifiable data taken directly from an authoritative source that represents a factual, reproducible observation of system attributes, such as state, configuration, or behavior. The accompanying note excludes probabilistic inferences, generative outputs, and predictive assessments from the factual system-state record. It says those outputs must not be used to generate deterministic telemetry. A plausible explanation is therefore not a substitute for the observation the definition describes. This definition addresses deterministic telemetry. Treating it as a statement that every possible AI use is prohibited would go beyond its stated subject. The workflow suggestions below concern how to keep explanations distinct from observations; they do not establish approval for a particular AI system or deployment. ## Preserve a trace from the summary to its inputs A practical design is to retain the original observation with its source, collection time, and resource identity, then keep any generated explanation as a separate derived item. Link the explanation to the records it used and label it clearly. These are implementation suggestions, not fields prescribed by FRD-DTM. Consider a firewall example. An exported configuration describes a setting at a particular point in time. A generated paragraph interpreting that configuration is another object. Reviewers should be able to open the original record and assess the explanation against it, including its limitations. Do not let a summarization step silently replace a missing observation. If a collection fails, record the collection failure in your workflow. A generated reconstruction of what the system probably looked like does not become the direct observation described by FRD-DTM. ## Test the boundary during a product demonstration Use a concrete demonstration instead of asking whether a tool is “AI powered.” Suggested questions include: - Which system supplies the original observation? - Can a reviewer inspect the input without relying on a generated explanation? - How are the resource, collection time, and scope identified? - What happens when the input is missing or conflicts with the summary? - Can the team correct an explanation without altering the original record? Ask the demonstrator to show a failed or incomplete collection as well as a successful one. That makes the division between observed state and interpretation easier to assess. These are buyer evaluation questions, not FedRAMP certification criteria for vendors. ## Keep review conclusions separate from generated prose Use summaries to help your team locate and understand records, subject to your own security and data-handling decisions. Have the responsible reviewer check conclusions against the original observations before relying on them. The useful operating test is whether the evidence remains understandable when the generated paragraph is removed. For the broader collection process, see the [KSI evidence workflow](/blog/20x/fedramp-20x-ksi). Keep FRD-DTM's narrower question visible throughout that process: is this item a direct, verifiable observation, or an interpretation of one? ### FedRAMP 20x Phase 4: What Proposed Agency Participation Means for Providers - URL: https://boundera.io/blog/20x/fedramp-20x-phase4-agency-participation-proposal - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T22:55:25.202033+00:00 - Updated: 2026-10-10T22:57:44Z - Reading time: 3 minutes - Main question: What agency-engagement decisions does RFC-0034 raise for prospective FedRAMP 20x Phase 4 providers? - TL;DR: RFC-0034 proposes TAG details and agency participation in Phase 4. Early materials access depends on provider agreement, liaison engagement is optional, and Board briefings are a separate proposed pilot expectation. The goal of three agency ATOs is not a guarantee to participants. - Excerpt: Read RFC-0034's proposed agency channels separately: TAG details, consent-based early access, optional liaison support and proposed pilot briefings. For a provider planning around FedRAMP 20x Phase 4, agency participation raises decisions about early access, technical support, and briefings. [RFC-0034](https://www.fedramp.gov/rfcs/0034/) proposes several ways agencies could engage. Read them as proposed arrangements, with different conditions for each channel. This article reflects the RFC checked on October 10, 2026. It does not announce an open enrollment process or a final pilot requirement. The proposal's agency-engagement topic is separate from the infrastructure tracks discussed in our [RFC-0033 explainer](/blog/20x/fedramp-20x-self-hosted-hybrid-rfc-0033-proposal). ## Understand the proposed TAG role RFC-0034 proposes agency security staff joining the Technical Advisory Group through reimbursable details of up to six months. It describes four days each week embedded with FedRAMP and one day at the home agency. The planned initial cohort would open in October 2026 with up to ten members; the RFC says process, timing, and expectations would be communicated separately through interagency channels. For a provider, the useful planning implication is to prepare for technically informed agency questions about the service and its assurance information. That is an implementation suggestion, not a new duty created by this article. Identify who can explain your evidence and demonstrate the service without turning every question into an executive escalation. ## Make early package access an explicit decision Under the proposal, TAG members could participate in support, review, and certification work for a service their agency intends to use. Early agency access to FedRAMP materials would depend on the provider's agreement. Do not summarize that conditional access as an automatic release of every pilot participant's materials. Prepare an internal access decision covering the materials to be shared, the intended recipients, the technical contact, and how questions will be tracked. Those are suggested planning fields. Review the applicable final process and existing sharing obligations before acting on the proposal. ## Distinguish optional liaison support from proposed pilot briefings RFC-0034 proposes sharing pilot progress with the Agency Liaison group through participant briefings and dedicated support meetings. It conditions that engagement on the participant being willing to support the group and describes liaison engagement as optional. Separately, the RFC proposes requirements for pilot participants to brief the FedRAMP Board. It also proposes end-of-pilot FedRAMP Day participation for participants on track to receive a 20x Class D certification. These are proposed pilot expectations in the RFC; they are not interchangeable with optional liaison engagement. A practical planning table can separate each audience, the expected subject matter, who would attend from your team, and whether the current source describes a proposal, a condition, or a final requirement. Update that table when official follow-up materials arrive. ## Treat agency ATOs as a goal, not a guaranteed outcome The RFC states a goal of at least three agencies completing an authorization to operate based on Phase 4 pilot packages during the pilot. It does not promise an ATO to each participant. Keep that distinction in sales discussions and internal forecasts. Use the proposal to prepare for substantive agency engagement: accessible materials, staff who understand them, and a way to resolve questions. Confirm final participation arrangements and timing from subsequent official communications before committing your calendar or representing a proposed opportunity as available. ### Validate FedRAMP 20x JSON Artifacts: Schema Errors, Extra Fields, and Evidence Limits - URL: https://boundera.io/blog/20x/fedramp-20x-json-schema-validation-workflow - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T22:53:45.812542+00:00 - Updated: 2026-10-10T22:55:48Z - Reading time: 3 minutes - Main question: How should engineering teams use FedRAMP 20x JSON schema validation in their artifact workflow? - TL;DR: Choose the official schema for the artifact, validate the generated JSON, fix exporter errors and repeat. Extra fields alone do not fail the official validator. Review the accuracy of the information and evidence separately from structural validity. - Excerpt: Select the correct artifact schema, fix errors in the exporter, inspect extra fields and review evidence meaning after the structural check. Use FedRAMP 20x JSON schema validation as a repeatable check on an exported artifact. Keep two questions separate in your workflow: does the document have the expected structure, and does its content accurately describe the service and evidence? A structural check is useful, but it cannot answer the second question for your team. ## Choose the schema for the artifact The official [FedRAMP schema catalog](https://www.fedramp.gov/schemas/) describes schemas as the structure of submission documents. It lists separate schemas for artifacts including the Certification Package Overview, Security Decision Record, Incident Report, and Vulnerability Detail Report. Select the artifact you are actually producing rather than testing every export against one generic package format. As an implementation practice, record the schema URL, retrieved version, export version, and validation date together. Retain the exact input used for the check according to your own evidence-handling policies. This gives an engineer enough context to reproduce a failure after the exporter changes. ## Check the exported JSON and investigate failures The official [JSON Schema Validator](https://www.fedramp.gov/schemas/validator/) lets you choose a schema and paste JSON or retrieve it from a URL. Its page says validation occurs in the browser and the document is not sent elsewhere for validation. This description applies to that official tool, not to arbitrary third-party validators. A suggested engineering sequence is: 1. Generate the artifact through the normal exporter. 2. Select its corresponding schema and validate that exact output. 3. Read each reported issue alongside the schema and affected JSON value. 4. Fix the producing system when the error originates in the exporter. 5. Regenerate the artifact and repeat the check. For example, if a field has the wrong type, investigate why the exporter produced that representation. A manual edit that makes one downloaded file pass may leave the next generated file broken. Keep a small regression example for the exporter issue without copying sensitive production content into a test fixture. These steps are implementation suggestions. They do not prescribe a particular programming library or add an official FedRAMP test artifact. ## Handle extra fields deliberately The official validator describes FedRAMP schemas as a minimum specification. Additional fields do not by themselves fail validation, and unrecognized top-level fields are displayed as informational notes. Treat those notes as a review opportunity. An extra field may be an intentional extension, or it may be a misspelled field your exporter was meant to populate. Check its purpose before deleting it or declaring it harmless. Also test the intended receiving system: the validator's acceptance of an extension does not tell you how every consumer will use that extension. ## Review meaning after structure For a Class B or C evidence workflow, the [Independent Verification and Validation rules](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation/) separately require supplying evidence of implementation and effectiveness to necessary assessors through IVV-CSO-SEI and IVV-CSO-SEE. A successful JSON structure check does not perform those evidence reviews. After schema validation, compare the exported identifiers, scope, statuses, and evidence references with the underlying records. Check that the intended recipient can retrieve the referenced material. Assign an owner to discrepancies instead of attaching a schema-success screenshot to an otherwise unreviewed export. Make the release decision explicit in your internal workflow: structure checked, meaning reviewed, and access exercised. These are suggested review stages, not a new certification status. Keep the validation output as one part of the evidence trail, alongside the work that establishes what the artifact actually means. ### FedRAMP 20x Incident Notifications: From Reportability to the Final Report - URL: https://boundera.io/blog/20x/fedramp-20x-incident-notification-workflow - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T22:52:26.103490+00:00 - Updated: 2026-10-10T22:54:36Z - Reading time: 4 minutes - Main question: How should FedRAMP 20x Class B and C teams organize incident reporting from evaluation to closure? - TL;DR: Evaluate reportability promptly, use PAIN-5 unless impact is promptly estimated under the rule, and track initial, ongoing and final reports separately. Class B and C timeframes differ. Report available information and follow the required recipient channels and agency-specific procedures. - Excerpt: Organize Class B and C incident communications from reportability and PAIN treatment through initial updates, ongoing reports and recovery closure. During an incident, the hard part of reporting is keeping the assessment, recipients, and next deadline aligned while facts change. For FedRAMP 20x Class B and Class C providers, build that sequence into the incident workflow before it is needed. The current [Incident Evaluation and Communication rules](https://www.fedramp.gov/2026/providers/20x/rules/incident-evaluation-and-communication/) separate reportability, impact rating, initial reporting, ongoing updates, and a final report. The steps below explain those distinctions and suggest an internal handoff for each. They cover this FedRAMP workflow; check your agency-specific reporting procedures as well. ## Evaluate reportability and preserve the decision IEC-CSO-EFR requires prompt evaluation of whether an incident affects, or is likely to affect, the confidentiality or integrity of federal customer data. Incidents meeting that condition are FedRAMP Reportable Incidents and follow these reporting rules. Use that stated condition in your evaluation; do not replace it with a generic severity label from an internal incident tool. As a working practice, record the evaluator, evidence available, evaluation time, affected data, and reasons for the decision. Revisit the record when new information changes the understanding of customer effects. Those record fields are suggested implementation details, not an additional official form. ## Apply the impact rating without waiting indefinitely IEC-CSO-EFI says providers SHOULD promptly estimate likely adverse impact on agency customers and assign the Potential Agency Impact N-rating, or PAIN. IEC-CSO-DPR requires treating a reportable incident as PAIN-5 unless the provider promptly performs that estimate under EFI. Do not use “rating pending” as an internal reason to leave the reporting workflow without a deadline. Assign an owner for the estimate and make the default treatment visible in your tracker. Keep the historical and current estimates together so later reports can explain how the assessment changed. ## Send the initial report with the information available IEC-CSO-IIR requires Class B and C providers to responsibly notify all affected parties with an Initial Incident Report containing as much of the listed information as is available, or the current relevant status. The list covers the incident coordinator, internal identifier, description, timeline, historical and current PAIN estimate with applicable explanation, functional impact, recovery plan and likely affected agencies. The rule's initial-report timeframes differ by class and rating: | PAIN rating | Class B | Class C | | --- | --- | --- | | 5, 4 or 3 | 6 hours | 1 hour | | 2 | 1 business day | 24 hours | | 1 | 1 business day | 1 business day | Use the current rule's workflow and definitions when implementing the clock. The illustrated workflow starts the reporting clock after the impact estimate or default PAIN treatment. Preserve the reportability evaluation time as part of the incident timeline. Do not wait for a completed root-cause investigation before supplying the available initial information. The reporting instructions identify FedRAMP's security email, agency-specific recipient methods, and the trust-center or USDA Connect update channel for necessary parties. Configure recipient handling from those instructions and the applicable agency process rather than assuming one email reaches everyone. ## Schedule ongoing updates separately from the initial report IEC-CSO-OIR requires Class B and C ongoing reporting as information becomes available during incident response. It includes updates, or lack of updates, to prior information and available information about observed activity, indicators of compromise, applicable CVEs, root cause, and response or recovery activities. For Class B, the table specifies one business day across PAIN-1 through PAIN-5. For Class C, it specifies six hours for PAIN-3 through PAIN-5, 24 hours for PAIN-2, and one business day for PAIN-1. Keep the next update deadline in the incident record, even when the technical investigation has produced no new conclusion. ## Close the reporting cycle after recovery IEC-CSO-FIR requires a Final Incident Report after the incident is resolved and recovery is complete, with final updates to previously reported information. Class B's table gives three business days for PAIN-1 through PAIN-5. Class C's gives six hours for PAIN-3 through PAIN-5 and one business day for PAIN-1 and PAIN-2. Use a distinct final-report task so resolving the technical incident does not silently close the communication work. Reconcile recipients, timestamps, and the last impact estimate before marking that task complete. IEC-CSO-AIR recommends automation to minimize human intervention in reporting; a useful implementation is to populate the reporting workflow from the incident record while preserving the team's review responsibilities. The cited 20x rule set shows July 4, 2026 for initial certification, January 1, 2027 for ongoing certification, and grace ending at the first FedRAMP independent assessment started after January 1, 2027. Check the applicable adoption position when planning implementation. Rehearse the entire reporting sequence with a clearly labeled internal scenario before relying on it during an incident. ### FedRAMP 20x Secure Configuration Guide: Beyond the Responsibility Matrix - URL: https://boundera.io/blog/20x/fedramp-20x-secure-configuration-guide-customer-settings - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T22:52:49.581880+00:00 - Updated: 2026-10-10T22:54:13Z - Reading time: 3 minutes - Main question: What should a Class B or C FedRAMP 20x Secure Configuration Guide explain to customer administrators? - TL;DR: Explain the lifecycle of top-level administrative accounts and the security implications of their restricted settings. Put instructions for obtaining and using the guide in the Certification Package. Keep public availability, secure defaults and enhanced capabilities labeled with their SHOULD strength. - Excerpt: Turn Class B and C customer responsibilities into usable account and settings instructions, while preserving required versus recommended SCG elements. A responsibility matrix can identify a customer-owned task without telling the administrator how to perform it. A useful FedRAMP 20x Secure Configuration Guide closes that gap: it connects a setting, the account that controls it, and the security effect of the customer's choice. This guide focuses on the current Class B and Class C provider rules. FedRAMP's [June 2026 transition notice](https://www.fedramp.gov/notices/0013/) described the Secure Configuration Guide as replacing the Control Implementation Summary / Customer Responsibility Matrix. For the actual contents and requirement strength, use the current [Secure Configuration Guide rules](https://www.fedramp.gov/2026/providers/20x/rules/secure-configuration-guide/). ## Start with the customer's administrative tasks SCG-CSO-RSC requires providers to create, maintain, and make available secure configuration recommendations. Its required content covers instructions for securely accessing, configuring, operating, and decommissioning top-level administrative accounts that control enterprise access to the whole offering. It also requires explanations of security settings only those accounts can operate, including their security implications. Explanations for settings restricted to other privileged accounts are recommended. Build your content inventory around the product's actual account names and administrative screens. A suggested entry might include the setting name, account role, secure recommendation, steps to apply it, and the effect of changing it. Those fields are an editorial format, not a FedRAMP-prescribed template. For example, a customer-facing entry for an administrative session setting could explain who can change it, what behavior changes, and how the administrator confirms the result. Use a value supported by your product's security design. Do not invent a universal FedRAMP setting value where the rule asks you to explain your offering. ## Make the instructions usable from the package SCG-CSO-AUP requires instructions in the Certification Package explaining how to obtain and use the guide. The rule allows providers to choose an appropriate presentation for their customers. SCG-CSO-RSC likewise permits appropriate forms of guidance rather than requiring one specific document layout. Test the path a customer actually follows: start at the package instructions, open the guide, locate the named administrative account, and follow one configuration task. Record broken links, outdated screen labels, or prerequisites the guide assumes without explaining. This is a suggested usability check for your release process. Public availability has a different requirement strength: SCG-CSO-PUB says providers SHOULD make the guide public. Do not turn that recommendation into a blanket MUST, and do not confuse it with the separate obligation to supply package instructions for obtaining and using the guide. ## Separate secure defaults from enhanced capabilities SCG-CSO-SDF says settings for top-level administrative and privileged accounts SHOULD start at the recommended secure defaults when initially provisioned. The enhanced-capability rules also use SHOULD: - SCG-ENH-CMP: compare current account settings with recommended secure defaults. - SCG-ENH-EXP: export all security settings in a machine-readable format. - SCG-ENH-API: view and adjust security settings through an API or similar capability. - SCG-ENH-MRG: supply machine-readable guidance usable for comparisons. - SCG-ENH-VRH: provide versioning and release history for recommended secure defaults as they change. Use those distinctions when planning engineering work. A guide, a settings export, and a comparison feature serve related but different customer needs. Describe the capabilities your service actually supplies instead of promising that publishing instructions creates the rest. ## Review the guide when the product changes Assign a content owner for each administrative area and include guidance review in relevant release work. A suggested review should check renamed settings, new privileged roles, changed defaults, and instructions for decommissioning access. Preserve enough internal context to explain why a recommendation changed. The current 20x SCG page shows March 1, 2026 for obtaining and maintaining certification and July 1, 2026 as the grace-period end. These dates differ from the January 2027 maintenance dates on some other rule sets. Check the applicable SCG rules directly when setting your plan. The reader should leave the guide able to perform a task and understand its consequence. Keep the responsibility mapping as useful context, then supply the operational instructions that an administrator needs at the point of configuration. ### FedRAMP 20x Security Inbox: Keep Critical Messages from Going Unanswered - URL: https://boundera.io/blog/20x/fedramp-20x-security-inbox-response-workflow - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T22:50:04.098370+00:00 - Updated: 2026-10-10T22:51:39Z - Reading time: 4 minutes - Main question: How should a FedRAMP 20x Class B or C provider maintain a working Security Inbox response process? - TL;DR: For Class B and C, maintain the contact address, notify FedRAMP immediately when it changes, test external delivery, and route messages by designation. Complete Emergency and Emergency Test actions within the message timeframe; track acknowledgment separately from completion. - Excerpt: Rehearse the Class B or C workflow from an external FedRAMP message to an owner, the required action and completion within the message timeframe. A security email address is useful only if a message reaches someone who can act. This workflow focuses on FedRAMP 20x Class B and Class C offerings. The operational check is straightforward: can an external message enter the inbox, reach the right owner, and produce the action requested within its deadline? FedRAMP's [July 2026 Security Inbox test notice](https://www.fedramp.gov/notices/0016/) described delivery and response failures, including bounced messages and poorly maintained ticketing routes. Its named providers and remediation dates were historical results of that test. Use the notice to understand the failure pattern; use the current [Addressing FedRAMP Communication rules](https://www.fedramp.gov/2026/providers/20x/rules/addressing-fedramp-communication/) to design your workflow. ## Keep the contact connected to an operating team AFC-CSO-INB requires providers to establish and maintain an email address for FedRAMP messages, called the FedRAMP Security Inbox. Its notes say FedRAMP uses the Marketplace Security Email unless told otherwise and warn about tying the inbox to one individual. AFC-CSO-NOC requires immediate notification to FedRAMP when the inbox address changes; the rule links the Notification of Changes form. As an implementation practice, assign a primary owner and backup, then document what happens during leave or a personnel change. Check the Marketplace contact against the actual routing configuration. A forwarding rule that still points to a former employee should create a concrete repair task, even if the public email address looks correct. Do not assume updating an internal ticket queue updates FedRAMP's contact information. Follow the official notification process for an address change and test the resulting delivery path. ## Test delivery without adding work for FedRAMP AFC-CSO-RCV requires receiving and reacting to FedRAMP emails without disruption or extra actions by FedRAMP. Its examples include avoiding a CAPTCHA, a customer portal login, or other service-specific steps that prevent the security team from receiving the message. Test the route from outside your organization. Inspect quarantine handling, automated ticket creation, assignment, and escalation. The purpose of this suggested test is to find where a delivered email becomes an unattended ticket. Record the observed result and fix the specific failure; do not stop after confirming that the mailbox exists. AFC-CSO-TFG says messages originating from @fedramp.gov or @gsa.gov are treated as FedRAMP messages by default, unless confirmed to originate from someone other than FedRAMP. That wording is not an instruction to disable normal email security controls. Keep your team's authenticity checks while making sure legitimate communications reach the people responsible for them. ## Route according to the message designation The rules distinguish message handling rather than assigning one universal response deadline: | Designation or activity | Official expectation | Suggested internal handoff | | --- | --- | --- | | Emergency or Emergency Test | AFC-CSO-CRA says required actions MUST be completed within the message's timeframe. | Assign an action owner and record the deadline from the message. | | Emergency | AFC-CSO-EMR says the message MUST reach a senior security official for awareness. | Include the senior official in the escalation path. | | Important | AFC-CSO-IMA says required actions SHOULD be completed within the specified timeframe. | Track the requested action and its due time. | | Receipt acknowledgment | AFC-CSO-ACK says providers SHOULD promptly and automatically acknowledge receipt. | Check the acknowledgment separately from action completion. | The rules note that action timeframes may vary by certification class. Read the deadline in each message. Do not substitute an internal support-service target or treat an automatic reply as proof that the required action is complete. ## Exercise the whole route and preserve the result Run an internal rehearsal with a clearly labeled test message. Have the receiving owner identify its designation, route it, assign the action, and record completion. Include an unavailable-primary-owner scenario so the backup process gets exercised. These rehearsal steps are practical suggestions, not an additional official FedRAMP testing schedule. Keep a simple internal record of receipt, assignment, escalation where relevant, requested action, and completion. Review failures with the mail and ticketing administrators together. A working mailbox and a working ticket system can still leave a gap at the handoff between them. The current 20x rule page lists January 5, 2026 for obtaining and maintaining certification, with the adoption grace period ending July 1, 2026. Do not apply the January 2027 maintenance date from other CR26 rule sets to this communication workflow. Check the current rule page when updating your runbook, and repeat the delivery rehearsal after routing or personnel changes. ### Self-Hosted Services and FedRAMP 20x: What RFC-0033 Proposes - URL: https://boundera.io/blog/20x/fedramp-20x-self-hosted-hybrid-rfc-0033-proposal - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T22:46:58.077956+00:00 - Updated: 2026-10-10T22:50:25Z - Reading time: 4 minutes - Main question: What does RFC-0033 propose for FedRAMP 20x self-hosted and hybrid-hosted services? - TL;DR: RFC-0033 proposes a provider engagement track to develop self-hosted and hybrid-hosted criteria for the 2027 rules. It is distinct from the Class D cloud-hosted pilot. Prepare infrastructure responsibility and assurance-gap questions; do not treat proposed reuse or target dates as final approval. - Excerpt: Separate the proposed self-hosted infrastructure engagement track from the Class D cloud-hosted pilot, then prepare specific assurance questions. If your service depends on physical infrastructure your company operates, the proposed FedRAMP 20x expansion raises a practical question: what work can you prepare before the new criteria exist? Start by separating the infrastructure engagement track from the Class D cloud-hosted pilot. They have different purposes and proposed participation criteria. This article explains [RFC-0033](https://www.fedramp.gov/rfcs/0033/) as reviewed on October 10, 2026. The RFC proposes an approach for Phase 4; it explicitly says details and timelines may shift with public comment. Its plans for self-hosted and hybrid-hosted services are not a certification approval or a promise that a particular infrastructure audit will be accepted. ## Identify who is responsible for the physical infrastructure RFC-0033 proposes three hosting definitions. Cloud-hosted offerings primarily run on third-party cloud offerings, with the provider not responsible for the physical infrastructure. Self-hosted offerings primarily run on infrastructure operated by the provider directly or through a third-party agreement, with the provider taking responsibility for that infrastructure. The proposal includes colocated or third-party-managed infrastructure when that responsibility remains with the provider. Hybrid-hosted combines cloud-hosted and self-hosted resources. For planning, write down who operates and who takes responsibility for each facility and infrastructure layer. A colocation contract alone does not answer the question the proposed definition asks. Treat the definitions as RFC proposals when describing your situation internally or to a prospective customer. ## Separate the three proposed tracks The RFC describes three concurrent Phase 4 tracks: | Proposed track | Purpose | Planning implication | | --- | --- | --- | | Track 1 | A Class D pilot for cloud-hosted services | Read the pilot's proposed prerequisites separately. | | Track 2 | Engagement with providers to develop self-hosted and hybrid-hosted requirements | Prepare evidence about infrastructure assurance and gaps. | | Track 3 | Engagement with independent assessors to develop assessment requirements | Identify assessment questions that need a consistent answer. | Track 2 aims to inform expanded criteria in the Consolidated Rules for 2027 for self-hosted or hybrid-hosted services of any Class. It is broader than a Class D-only infrastructure discussion. Conversely, participation in a requirements-development discussion is not the same outcome as earning a pilot certification. For direct provider engagement, the RFC proposes that participants be Rev5 Class C or D certified, have at least 15 agency uses on record, and be primarily self-hosted or hybrid-hosted. Providers with multiple qualifying offerings would count once. The proposal says FedRAMP would identify qualifying providers using Marketplace information and notify them through the FedRAMP Security Inbox. These criteria describe the proposed engagement track, not general 20x certification eligibility. ## Prepare a useful infrastructure assurance inventory Track 2 proposes examining widely used industry certifications and their differences from existing FedRAMP Rev5 requirements. FedRAMP's stated goal is to identify reusable certifications and classifications where possible for infrastructure-related controls. That goal is not blanket recognition of every existing audit. A useful preparation exercise is to build an internal comparison with these fields: - Infrastructure component and responsible organization. - Existing certification or assessment, including its scope and period. - Activities or facilities outside that assessment's scope. - Supporting evidence you can share appropriately. - Specific question about reuse that future rules would need to resolve. These fields are our suggested working format. Do not label the result an official application or assume it satisfies unpublished criteria. For example, if an assessment covers a facility but excludes a service you operate within it, flag the gap explicitly. That makes the question more useful than simply asking whether the certificate “counts.” ## Treat target dates as targets RFC-0033 lists an October 12 notification target and October 16 opt-in response target for qualifying providers. It also proposes a November 4 RFC with general questions and a February 10, 2027 RFC on self-hosted or hybrid-hosted service rules. The source qualifies its timeline with the possibility of unexpected changes. As of this article's October 10 source check, those dates are planning targets in the RFC. Verify actual notifications and subsequent official publications before organizing work around them. Do not interpret an expected notification date as an open public certification application window. The RFC also says public questions and proposed rules will be published so that other parties can participate. A provider outside the targeted engagement criteria can prepare specific questions for those public processes. Check the relevant RFC's current comment instructions and dates when responding. ## Keep customer commitments tied to published criteria For internal planning, maintain two lists: work useful under your existing commitments, and assumptions dependent on future 20x rules. Assign someone to update the second list when official notices or final requirements appear. This is a suggested planning practice, not a FedRAMP deliverable. The immediate value of the proposal is a clearer set of questions about physical infrastructure responsibility, existing assurance, and assessment gaps. Use it to prepare those questions. Describe future certification options conditionally until the applicable criteria and process are published. ### FedRAMP 20x Evidence Readiness Checklist - URL: https://boundera.io/blog/20x/fedramp-20x-evidence-readiness-checklist - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T22:47:55.675338+00:00 - Updated: 2026-10-10T22:49:32Z - Reading time: 5 minutes - Main question: How can a Class B or C team check whether its FedRAMP 20x evidence is ready for a reviewer? - TL;DR: Rehearse one evidence trail from the assessed resource to implementation, effectiveness, the Security Decision Record and reviewer access. Apply the correct class and rule dates, then give unresolved gaps an owner. This is an implementation checklist, not an official assessment. - Excerpt: Rehearse a Class B or C evidence handoff: connect scope, implementation, effectiveness, KSI summaries, metric history and reviewer access. An evidence folder can look complete while leaving an assessor unable to answer a basic question: does this measure work for the service being assessed? Use this FedRAMP 20x evidence readiness checklist as a rehearsal before sharing a package. Pick a security measure, follow its evidence, and check whether another person can reach the same conclusion. The checklist below is an implementation aid for teams preparing Class B or Class C offerings. It is not an official FedRAMP assessment or a complete inventory of applicable rules. Its purpose is to find broken handoffs between engineering, compliance, and the assessor. For collecting the evidence itself, see our [KSI evidence workflow](/blog/20x/fedramp-20x-ksi-evidence-automation). ## Establish the scope and rule version first Start the rehearsal with the service boundary. Under MAS-CSO-IIR, the assessed offering includes information resources likely to handle federal customer data or affect its confidentiality, integrity, or availability. MAS-CSO-FLO requires the information flows and security categories to be identified, documented, and explained. Those rules give the checklist a concrete boundary; a passing test against an unrelated environment does not answer your readiness question. See the [Minimum Assessment Scope rules](https://www.fedramp.gov/2026/providers/20x/rules/minimum-assessment-scope/). Record the class, rule version, service environment, and date used for the rehearsal. The rule sets cited here show July 4, 2026 for obtaining initial certification, January 1, 2027 for maintaining ongoing certification, and a grace period ending at the first FedRAMP independent assessment started after January 1, 2027. Check those applicability details before treating a future maintenance expectation as an overdue task today. ## Walk one measure from implementation to effectiveness The [Independent Verification and Validation rules](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation/) distinguish evidence of implementation, IVV-CSO-SEI, from evidence of effectiveness, IVV-CSO-SEE. Providers must supply both to all necessary assessors for measures documented or implemented to meet FedRAMP Practices. A configuration record and a behavioral test answer different questions. For an illustrative firewall measure, use this rehearsal: 1. Locate the deployed configuration and identify which assessed resources it covers. 2. Open the result that demonstrates the intended traffic behavior. 3. Compare the configuration version, test target, and execution time. 4. Explain any resources or paths the result does not cover. 5. Ask a colleague who did not build the check to repeat the trace. These are suggested working steps, not an additional FedRAMP test procedure. A result that cannot be connected to a resource or measure should create a follow-up task with an owner. Avoid treating an attractive dashboard as sufficient evidence without opening the records behind it. ## Check that the Security Decision Record explains the evidence SDR-CSX-KSI requires short, high-level summaries for each applicable KSI. These include the measures and their objectives, the cycle for persistent measures where applicable, verification, the adequacy of automation or why it is unnecessary, and validation. For unavailable measures, the rule calls for the reason and resulting risk to customers, verification that the reason is accepted, and validation that it is valid. Read the full [Security Decision Record rule](https://www.fedramp.gov/2026/providers/20x/rules/security-decision-record/) before assigning a simple green status. For the rehearsal, put the summary beside the underlying evidence. Can the reviewer tell which measure the result supports? Does the summary acknowledge an unavailable measure, instead of silently omitting it? Are changes in the implementation reflected in the explanation? Record these as editorial review questions for your team; do not invent a new official artifact name for the worksheet. Historical metrics need a separate check. As of the October 8, 2026 rule update, SDR-CSX-KMT says Class B providers SHOULD include the specified historical summaries. Class C providers MUST include those summaries and daily metric data, including persistent validation status, up to the past year where available. For initial certification where the relevant operating history is unavailable, the note calls for mechanisms to be in place and an agreement to meet the requirement. Do not manufacture history to fill a chart. ## Rehearse the package handoff Check that the person reviewing the package can open the same evidence your team used. CDS-CSO-UTC requires a FedRAMP-compatible trust center for storing and sharing Certification Data with all necessary parties. CDS-CSO-CBF requires automation to keep human-readable and machine-readable information consistent when both are supplied. These are distinct checks in the [Certification Data Sharing rules](https://www.fedramp.gov/2026/providers/20x/rules/certification-data-sharing/). Use an appropriately authorized test account to exercise the handoff. Open a human-readable summary, retrieve its machine-readable counterpart, and compare the selected service, status, and referenced evidence. Treat a denied link or mismatched result as a release issue to investigate. This test-account approach is suggested practice, not a prescribed FedRAMP account model. Also check the assessment results after presentation or formatting changes. IVV-CSO-ICP requires their inclusion in the Certification Package without inappropriate modification. The source explains that formatting can change, but the assessor's underlying intent cannot. Keep the original assessment result available for comparison during your editorial review. ## Give readiness a repeatable owner Use a short internal record for each rehearsal: measure reviewed, evidence location, reviewer, unresolved issue, responsible owner, and next check. Those fields are a suggested management aid. The useful outcome is a clear list of gaps someone can close, rather than a percentage that hides missing evidence. Package maintenance has its own cadence. CPO-CSX-CPM requires Class B packages to be up to date and complete at least monthly and Class C packages at least every two weeks. Its notes expect automation as changes occur and explicitly say the cadence does not require persistent human review of every material. See [Certification Package Overview](https://www.fedramp.gov/2026/providers/20x/rules/certification-package-overview/). Before the handoff, resolve or clearly record mismatched scope, inaccessible evidence, missing explanations, and differences between formats. Keep the rehearsal focused on whether a reviewer can follow the evidence. Use the [engineering readiness guide](/blog/20x/engineering-readiness-fedramp-20x) to assign the broader engineering work that the rehearsal uncovers. ### FedRAMP 20x Class A: Separate Reporting from the Audit Cycle - URL: https://boundera.io/blog/20x/fedramp-20x-class-a-reporting-audit-calendar - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-10T21:40:20.148611+00:00 - Updated: 2026-10-10T21:43:44Z - Reading time: 5 minutes - Main question: How should a FedRAMP 20x Class A provider organize its reporting and assessment calendar? - TL;DR: Class A incorporates an Ongoing Certification Report every three months and publication of the next report target date. A synchronous Quarterly Review is optional. Keep those tasks separate from the assessment expectations of the underlying alternative security framework. - Excerpt: Build a Class A calendar that separates the three-month report, public next-report date, optional review meeting and underlying framework assessment. For your FedRAMP 20x Class A reporting calendar, start with separate entries for the Ongoing Certification Report, the next public report date, and your underlying framework's assessment milestones. Then decide whether a review meeting would help your agency customers. The distinction matters: Class A incorporates a report every three months, while its synchronous Quarterly Review is optional. Its independent-assessment rule points to the expectations of the underlying alternative security framework. Those are separate obligations and choices, even when the same compliance team coordinates them. [FedRAMP Class A rules](https://www.fedramp.gov/2026/reference/20x/a/related) ## Identify the Class A rules before scheduling work FRC-CLA-MFR explicitly includes CCM-OCR-AVL, CCM-OCR-NRD and IVV-CSX-AIA among the additional rules Class A providers must address. This cross-reference is the basis for applying the reporting and assessment requirements here. The report is one part of the Class A package; FRC-CLA-MFR lists other responsibilities too. [FedRAMP Certification](https://www.fedramp.gov/2026/providers/20x/rules/fedramp-certification) Use the following distinction when assigning calendar owners: | Calendar item | Class A rule | What to schedule | | --- | --- | --- | | Ongoing Certification Report | CCM-OCR-AVL: MUST | Supply a report every three months, covering the entire period since the previous summary. | | Next report target date | CCM-OCR-NRD: MUST | Supply the next report's target date with other public Certification Data. | | Synchronous Quarterly Review | CCM-QTR-MTG: MAY | If you choose to hold the review, plan the three-month cycle and invite all necessary parties. | | Underlying framework assessment | IVV-CSX-AIA: MUST | Meet the underlying alternative framework's assessment expectations. | The Class A variants and mandatory/optional groupings appear in the [official related-rules reference](https://www.fedramp.gov/2026/reference/20x/a/related). Do not use the title “Annual Independent Assessments for 20x” alone to decide what the Class A variant requires. ## Build the report around a continuous coverage period CCM-OCR-AVL requires a consistent, human-readable Ongoing Certification Report supplied to all necessary parties every three months. It covers the entire period since the previous summary. The required high-level contents apply where relevant to the certification type or class. [Report Availability](https://www.fedramp.gov/2026/reference/20x/a/related#mandatory-class-a-rules-collaborative-continuous-monitoring-ccm) The rule's list covers these areas, if applicable: - Changes to Certification Data and planned changes during at least the next three months. - Accepted vulnerabilities and transformative changes. - Updated recommendations for security, configuration, usage or similar aspects of the offering. - Agencies directly using the product. - FedRAMP Reportable Incidents, or an attestation that none occurred, plus lessons learned and resulting changes when incidents did occur. These are summaries of the contents specified in [CCM-OCR-AVL](https://www.fedramp.gov/2026/reference/20x/a/related#mandatory-class-a-rules-collaborative-continuous-monitoring-ccm). Keep the applicability qualifier when preparing the report; avoid filling a section with invented activity just to make the document look complete. As an operating practice, give each report a coverage start, coverage end, delivery date, owner and link to the preceding report. Before release, compare adjacent coverage periods for gaps. Keep references to the records behind each summary so a reviewer can follow the explanation without restarting the research. For example, a team could use an internal worksheet with one row per reporting period, another field for the next target date, and a separate preparation deadline for contributors. This is a suggested workflow, not a FedRAMP template or an additional mandated lead time. Pick preparation deadlines that fit your review process while preserving the rule's three-month reporting cadence. ## Keep the next public date separate from report delivery CCM-OCR-NRD requires the target date of the next Ongoing Certification Report to accompany other public FedRAMP Certification Data. Supplying the report and supplying that public date are both included in the mandatory Class A cross-reference. [Class A related rules](https://www.fedramp.gov/2026/reference/20x/a/related) Assign an owner to check that the public date and the team's internal schedule agree. As a release check, open the public data surface and compare its next-report date with the approved schedule. Retain the check result alongside the report's delivery record. These are suggested coordination steps; the rule does not prescribe this particular checklist. If you are organizing the broader package delivery process, the [authorization data sharing workflow](/blog/20x/fedramp-20x-authorization-data-sharing-workflow) provides related operational context. ## Decide on the meeting without changing the report obligation For Class A, CCM-QTR-MTG uses MAY for a synchronous Quarterly Review every three months, open to all necessary parties. FRC-CLA-OFR also places that meeting rule among the optional Class A rules. The mandatory report remains separately listed in FRC-CLA-MFR. [Class A certification rules](https://www.fedramp.gov/2026/providers/20x/rules/fedramp-certification) and [Quarterly Review Meeting](https://www.fedramp.gov/2026/reference/20x/a/related#optional-class-a-rules-collaborative-continuous-monitoring-ccm) Choose a meeting when discussion would help customers understand a meaningful change or resolve questions. Keep the decision to host it separate from the report-delivery task. An internal calendar can mark the meeting as an optional customer discussion while keeping report preparation and delivery assigned to named owners. ## Maintain a separate assessment schedule The Class A variant of IVV-CSX-AIA requires providers to meet their underlying alternative security framework's expectations as part of persistent independent verification and validation. It does not state a universal SOC 2 or GovRAMP renewal interval. The separate IVV-CSO-FIA Class A variant makes a FedRAMP independent assessment at least once per year optional. [Independent Verification and Validation](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation) For SOC 2-based Class A applications, FRC-CLA-EAM includes an estimated schedule for the upcoming report among the external assessment materials, alongside the complete report, verified audit engagement documentation and applicable bridge/gap letters and supplemental evidence. That schedule is distinct from the next Ongoing Certification Report date. [External Assessment Materials](https://www.fedramp.gov/2026/providers/20x/rules/fedramp-certification#external-assessment-materials) As a practical step, review the assessment milestones with the people responsible for the underlying framework. Record the expected report date, preparation work and evidence owners in separate calendar entries. Our [SOC 2-to-Class A](/blog/20x/soc-2-to-fedramp-20x-class-a) and [GovRAMP-to-Class A](/blog/20x/govramp-to-fedramp-20x-class-a) articles address entry-package questions; this calendar addresses the ongoing coordination work. ## Record the applicable adoption dates As checked on October 10, 2026, the FRC, CCM and IVV rulesets list July 4, 2026 for optional adoption and obtaining initial 20x certification, and January 1, 2027 for maintaining ongoing 20x certification. Their published grace language ends the grace period at the first FedRAMP independent assessment started after January 1, 2027. These are ruleset applicability dates, not a substitute for the recurring report schedule. [FRC dates](https://www.fedramp.gov/2026/providers/20x/rules/fedramp-certification), [CCM dates](https://www.fedramp.gov/2026/providers/20x/rules/collaborative-continuous-monitoring), [IVV dates](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation) Record the applicable adoption basis in your operating calendar and recheck the current official rules when circumstances change. Avoid interpreting grace language as a blanket permission to postpone every Class A duty until an unspecified future audit. ### FedRAMP 20x: Respond to Serious Agency Monitoring Concerns - URL: https://boundera.io/blog/20x/fedramp-20x-agency-monitoring-concern-escalation - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-10-01T14:04:28.401Z - Updated: 2026-10-01T14:13:00Z - Reading time: 5 minutes - Main question: How should a FedRAMP 20x provider respond to serious agency monitoring concerns? - TL;DR: The published agency-use rules say agencies MUST notify FedRAMP and SHOULD formally notify the provider when information in an Ongoing Certification Report, Quarterly Review, or other FedRAMP Certification Data causes significant concerns for the authorizing official likely to result in rescission of their ATO. For provider follow-up, preserve the report version, name an owner, and return evidence with unresolved questions clearly identified. - Excerpt: A practical provider response to serious agency monitoring concerns: understand the notification threshold, preserve the evidence, and coordinate follow-up. An agency customer flags a monitoring report and asks whether it can keep using your service. Start by preserving the exact concern, the report version, and the agency's stated impact. Assign a provider response owner who can return evidence and explain what remains unresolved. For FedRAMP 20x agency monitoring concerns, the published agency-use rules distinguish two notifications: agencies MUST notify FedRAMP and SHOULD formally notify the provider when the specified significant-concern threshold is met. The threshold concerns information in an Ongoing Certification Report, Quarterly Review, or other FedRAMP Certification Data that causes significant concerns for the authorizing official likely to result in rescission of their Authorization to Operate (ATO). [AGU-USE-NFC and AGU-USE-NPC](https://www.fedramp.gov/2026/agencies/rules/agency-use#notify-fedramp-of-monitoring-concerns) ## Read the published rule and its scope The agency-use page identifies its rules as required under the Consolidated Rules for 2026 and lists July 4, 2026 for initial certification, ongoing certification, and the end of the grace period. The Use of FedRAMP Certifications subset applies when agencies use certifications to make authorization decisions and includes 20x. [Published applicability](https://www.fedramp.gov/2026/agencies/rules/agency-use#use-of-fedramp-certifications) Source status checked October 1, 2026: the underlying rules JSON retains a conflicting document-status label alongside that required/effective metadata. This article describes the published text without resolving that inconsistency or presenting it as a newly finalized change. [Canonical AGU metadata](https://github.com/FedRAMP/rules/blob/main/fedramp-consolidated-rules.json) Read the trigger as a whole. The named information source, significance to the authorizing official, and likelihood of ATO rescission all belong in the threshold. AGU-USE-NFC does not say every unfavorable finding triggers this notification. It also does not require an agency to wait for an ATO to be rescinded before notifying FedRAMP. [Notification trigger](https://www.fedramp.gov/2026/agencies/rules/agency-use#notify-fedramp-of-monitoring-concerns) For provider triage, ask the agency to identify the affected use of the service and explain the concern in its own terms. Avoid substituting a provider severity score for the agency's assessment of its authorization risk. ## Keep the two notification routes distinct **Notification to FedRAMP — AGU-USE-NFC.** Agencies MUST notify FedRAMP when certification information from an Ongoing Certification Report, Quarterly Review, or other FedRAMP Certification Data causes significant concerns for the authorizing official likely to result in rescission of their ATO. The published route is the [Report Concerns on Ongoing Certifications form](https://help.fedramp.gov/hc/en-us/requests/new?ticket_form_id=51821301979547). [Rule and route](https://www.fedramp.gov/2026/agencies/rules/agency-use#notify-fedramp-of-monitoring-concerns) **Notification to the provider — AGU-USE-NPC.** Under the same information-source, significant-concern, and likely-rescission threshold, agencies SHOULD formally notify the cloud service provider. The published contact method is the provider's security contact email or form. [Rule and route](https://www.fedramp.gov/2026/agencies/rules/agency-use#notify-provider-of-concerns) SHOULD has a defined meaning here: valid reasons to depart may exist, but the implications must be weighed, and parties MUST explain how they handle such rules in their security documentation. Treating the provider notification as casual or consequence-free would miss that qualification. [FedRAMP definition of SHOULD](https://www.fedramp.gov/2026/definitions/#should) Keep your provider response record separate from the agency's notification record. The FedRAMP notification rule assigns the action to agencies; a provider support exchange is not the agency notification specified by AGU-USE-NFC. [Agency responsibility](https://www.fedramp.gov/2026/agencies/rules/agency-use#notify-fedramp-of-monitoring-concerns) ## Build a useful provider response record The following record and workflow are editorial recommendations for customer-security teams. They are not additional FedRAMP submission requirements or an official form. Capture these fields when a concern arrives: - **Source and version:** report title, date, version, section, and a stable reference to the information the agency reviewed. - **Agency context:** affected system or service use, agency contact, and the concern in the agency's own words. - **Open question:** what the agency needs clarified, which facts are disputed, and which questions remain unanswered. - **Provider owner:** one coordinating contact, with named technical contributors for the supporting evidence. - **Evidence and next step:** verified facts, relevant evidence references, corrective work proposed or completed, and an agreed next communication time. Preserve the original report alongside subsequent explanations. If you discover an error, label the correction and explain what changed instead of silently replacing the earlier evidence. Separate completed work from planned work so the agency can see what is demonstrable today. For example, suppose an agency points to a Quarterly Review and says a described change creates a serious problem for its system. Record that statement before debating the provider's interpretation. Ask the technical owner for evidence about the change and its scope. Return a response that separates confirmed facts, unresolved questions, and proposed actions. This is an illustrative response method; it does not determine whether the agency's rule threshold is met. For the broader report-reading task, see our guide to [vulnerability reports and agency risk review](/blog/20x/fedramp-20x-vulnerability-reports-agency-risk-review). If the conversation turns into a request for extra materials or security requirements, consult the separate discussion of [additional agency security requests](/blog/20x/fedramp-20x-additional-agency-requests). ## Preserve the agency's authorization role AGU-USE-ABU requires agencies to complete the ATO process for federal information systems that use FedRAMP Certified cloud service offerings. AGU-USE-RCF separately requires agencies to collaborate with FedRAMP when agency-specific security determinations conflict with, or differ from, the FedRAMP Certification Package. [Agency authorization and conflicts](https://www.fedramp.gov/2026/agencies/rules/agency-use#authorization-before-use) The two monitoring-concern notification rules describe agency notifications; they do not themselves declare an incident, revoke a FedRAMP certification, or prescribe a provider response deadline. [AGU-USE-NFC and AGU-USE-NPC](https://www.fedramp.gov/2026/agencies/rules/agency-use#notify-fedramp-of-monitoring-concerns) Set a response cadence with the agency and track it as a customer commitment. Avoid labeling a locally chosen turnaround time as a FedRAMP deadline. Keep the status of your provider work separate from the agency's authorization decision, and do not promise that an explanation or remediation will preserve its ATO. ## Questions for customer-security teams ### Does every unfavorable monitoring finding require notification to FedRAMP? No. AGU-USE-NFC specifies information in an Ongoing Certification Report, Quarterly Review, or other FedRAMP Certification Data that causes significant concerns for the authorizing official likely to result in rescission of their ATO. Preserve that full threshold when routing the concern. [AGU-USE-NFC](https://www.fedramp.gov/2026/agencies/rules/agency-use#notify-fedramp-of-monitoring-concerns) ### Is the provider notification also a MUST? AGU-USE-NPC uses SHOULD for the agency's formal notification to the provider under the same threshold; AGU-USE-NFC uses MUST for notifying FedRAMP. The defined SHOULD still requires parties to explain their handling of the rule in security documentation. [Notification rules](https://www.fedramp.gov/2026/agencies/rules/agency-use#notify-provider-of-concerns) and [SHOULD definition](https://www.fedramp.gov/2026/definitions/#should) ### What should the provider send back first? As a practical starting point, acknowledge the specific concern, name the response owner, identify the evidence being checked, and agree on the next contact. Make uncertainty visible and follow up with verified evidence rather than a promise about the agency's authorization outcome. ### FedRAMP 20x Annual Assessment Coverage: Build a Practical Map - URL: https://boundera.io/blog/20x/fedramp-20x-annual-assessment-coverage-map - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-09-28T14:05:08.028Z - Updated: 2026-09-28T14:12:00Z - Reading time: 5 minutes - Main question: How should a FedRAMP 20x team map annual assessment coverage across rules and KSIs? - TL;DR: Start with the applicable rule and KSI inventories. Connect each row to implementation evidence, effectiveness evidence, sampling explanations, an owner, and an assessor review reference. Keep applicability decisions, evidence coverage, and IVV transition dates visible in the working map. - Excerpt: Prepare an annual assessment coverage map that connects applicable rules and KSIs to evidence, sampling explanations, owners, and assessor review references. An assessment lead can have a folder full of evidence and still struggle to answer a basic question: which parts of the assessment does it cover? Start with a coverage map that connects each rule to its evidence and the assessor's review reference. Use it to find missing work before the assessment conversation reaches an unexplained blank. For FedRAMP 20x annual assessment coverage, build the map from the applicable rules and KSI inventory, then attach evidence. The workflow below is our suggested preparation method for Class B and Class C teams using Program Certification. ## Establish the annual assessment scope IVV-CSO-FIA requires Class B and Class C providers to complete independent verification and validation of all applicable FedRAMP rules at least once per year, using a FedRAMP Recognized independent assessment service or FedRAMP. Its notes limit direct assessment by FedRAMP to explicitly prioritized cloud services and describe that option as extremely rare. See the [FedRAMP Independent Assessments rule](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation/#fedramp-independent-assessments). For 20x Class B and Class C Program Certification, IVV-CSX-AIA requires all Key Security Indicators to be included in a FedRAMP independent assessment at least once per year. See [Annual Independent Assessments for 20x](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation/#annual-independent-assessments-for-20x). FedRAMP's assessor transition guidance also says each rule is to be verified and validated during each independent assessment. Read that guidance alongside the applicable-rule scope in IVV-CSO-FIA. See [What's Changing for Assessors](https://www.fedramp.gov/2026/assessors/updating/changes). For preparation, make separate checks for rule coverage and KSI coverage. Reconcile both lists against the map. Keep an applicability explanation beside any rule you propose excluding, and bring uncertain cases to the assessor. Avoid using the number of uploaded files as your measure of completeness. ## Keep the IVV transition dates beside the scope The 20x IVV ruleset lists July 4, 2026 for optional adoption and obtaining initial certification, and January 1, 2027 for maintaining ongoing certification. Its grace period ends on the first FedRAMP independent assessment started after January 1, 2027. See the [IVV effective dates and applicability notice](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation/). Record those dates separately from your planned assessment start and completion dates. Identify whether the engagement concerns initial or ongoing certification before applying the transition notice to your schedule. Use the notice's assessment-start wording when discussing the grace period. This article applies the published rules to assessment preparation. The coverage map below is our suggested working aid. ## Build a map the assessment team can navigate Begin with one row per rule or KSI in your working inventory. Split a row when it covers different implementations or owners that would be difficult to review together. Use stable identifiers so a change in a heading does not break the evidence trail. Suggested fields: | Field | What to record | | --- | --- | | Rule or KSI reference | Identifier, current official link, and the version or date checked. | | Applicability | Class, type, path, timing, and the reason for the team's scope decision. | | Implementation evidence | A reference showing the documented measure in place. | | Effectiveness evidence | A reference showing how the measure's result was evaluated. | | Evidence coverage | Systems, environments, time period, and any representative sample used. | | Owner and access | A responsible person, evidence location, and access instructions for the review. | | Assessment reference | The assessor's review or finding reference, plus unresolved questions. | Keep evidence in its maintained location and link to it from the map. Where a reference serves several rows, explain its relevance to each row. Where a row has no evidence yet, assign the next action and owner rather than filling the cell with an optimistic status. Review the map in both directions. From a rule, follow the link to evidence that addresses it. From an evidence item, check which rows rely on it. This is a useful preparation exercise for spotting a reused export that answers only part of the question. ## Separate implementation evidence from effectiveness evidence IVV-CSO-SEI requires providers to supply all necessary assessors with evidence that measures documented to meet FedRAMP Practices have been implemented; that evidence is the result of verification. IVV-CSO-SEE requires evidence of those measures' effectiveness; that evidence is the result of validation. See [Supply Evidence of Implementation](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation/#supply-evidence-of-implementation) and [Supply Evidence of Effectiveness](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation/#supply-evidence-of-effectiveness). Consider a hypothetical network restriction. In your map, link the deployed configuration under implementation evidence. Under effectiveness evidence, link the test or observed result used to evaluate whether the restriction works. Add the environment, collection time, and known limitations so the reviewer can understand the comparison. Treat a successful automated check as an evidence item to explain. Record what it evaluates, the data it reads, and the rule or KSI rows it supports. Keep the evidence-collection schedule and the annual assessment schedule as separate planning fields. For the broader evidence workflow, see our [KSI verification, validation, and history guide](/blog/20x/fedramp-20x-ksi). ## Document sampling alongside evidence coverage IVV-CSO-USR permits representative samples as appropriate during verification and validation. When providers use representative samples under that permission, IVV-CSO-DUS requires them to document and explain their use. See [Use Representative Samples](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation/#use-representative-samples) and [Document Use of Representative Samples](https://www.fedramp.gov/2026/providers/20x/rules/independent-verification-and-validation/#document-use-of-representative-samples). In the working map, keep the applicability decision separate from the sampling explanation. For a sampled evidence set, record the population, selected items, selection reasoning, relevant differences, and limitations. Discuss whether the sample supports the assessment question with the assessor. For example, suppose a team proposes reviewing a subset of deployment environments. Have the owner explain how those environments were selected and identify configuration differences across the full population. Leave the coverage question open until the review has addressed those differences. Avoid treating a smaller evidence set as a reason to remove unrelated rule rows. ## Use the map to prepare the next review Before the assessment meeting, walk through one complete row with an evidence owner. Open both evidence references, confirm that the reviewer can reach them, and capture the questions that remain. Then repeat the exercise for rows with shared evidence, sampling, or unresolved applicability. Bring a short list of gaps to the meeting: missing evidence, unclear scope, unexplained samples, and absent review references. Assign follow-up work from those concrete gaps. A useful map lets the team trace an assessment question to its evidence and record what still needs attention. ### FedRAMP 20x: Receiving Assessor Advice Without Losing Independence - URL: https://boundera.io/blog/20x/fedramp-20x-advice-during-independent-assessment - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-09-24T14:06:25.081Z - Updated: 2026-09-24T14:16:06Z - Reading time: 5 minutes - Main question: How should a FedRAMP 20x provider approach assessor advice during an independent assessment? - TL;DR: Providers may seek assessor advice during assessment on security posture or verification, validation, and reporting procedures, unless doing so is likely to compromise assessment objectivity and integrity. Check the separate two-year advisory-separation restriction and any applicable FedRAMP-published exception. Record the advice, provider decision, and assessor findings separately. - Excerpt: Plan assessor conversations with the advice permissions, advisory-separation restriction, and applicable dates in view. Use a practical record to track decisions. An assessment conversation can leave a provider with two decisions: whether to ask the assessor for technical advice, and how to handle that advice without blurring the assessment's independence. Start by identifying the question, the work being requested, and any earlier advisory engagement involving the same offering. For FedRAMP 20x advice during assessment, read the permission to exchange advice alongside the separate advisory-separation rule. Use the following workflow to prepare the conversation and identify questions that need authoritative clarification. ## What the advice permissions say Under IVV-CSO-RAA, providers MAY request and accept assessor advice during assessment on techniques and procedures to improve security posture or the effectiveness, clarity, and accuracy of verification, validation, and reporting. That permission excludes circumstances where doing so is likely to compromise the assessment's objectivity and integrity. See the official [Receiving Assessor Advice rule](https://github.com/FedRAMP/2026-markdown/blob/HEAD/reference/20x/c/independent-verification-and-validation.md#receiving-assessor-advice). IVV-IAS-SHA gives assessors a corresponding MAY permission to share advice with providers they are assessing on those same subjects, with the same objectivity-and-integrity condition. See [Sharing Advice](https://github.com/FedRAMP/2026-markdown/blob/HEAD/assessors/rules/independent-verification-and-validation.md#sharing-advice). FedRAMP defines MAY as an optional rule and says parties SHOULD explain in their security documentation how they handle such rules. Its definition of likely is a reasonable degree of probability based on context. These definitions matter when discussing a particular request; see the official [definitions](https://github.com/FedRAMP/2026-markdown/blob/HEAD/definitions.md). As a practical step, ask the assessor to consider the proposed interaction before advice is exchanged. Describe the actual activity and its intended outcome, rather than relying on an engagement label such as “assessment support.” ## Check previous advisory or consulting work REC-IAS-SEP prohibits an assessor from performing a FedRAMP independent assessment of the same cloud service offering within two years after supplying advisory or consulting services for that offering. The exception is a specific exception published by FedRAMP for a limited pilot or another explicitly scoped process. See [Advisory Separation](https://github.com/FedRAMP/2026-markdown/blob/HEAD/assessors/rules/fedramp-recognition.md#advisory-separation). Before scheduling work, collect the prior engagement's scope, deliverables, dates, and the offering involved. Ask the assessor to review those facts against REC-IAS-SEP. If someone proposes relying on an exception, locate the published exception and examine its scope together. Do not treat the advice permissions as a blanket consulting exemption. For an uncertain boundary between advice during assessment and advisory or consulting services, seek authoritative clarification from FedRAMP before relying on your interpretation. Avoid assuming that a new contract title settles the question. ## Keep the different effective dates visible The Recognition rules list July 4, 2026 for optional adoption, obtaining initial certification, maintaining ongoing certification, and the end of the grace period. See the [Recognition applicability notice](https://github.com/FedRAMP/2026-markdown/blob/HEAD/assessors/rules/fedramp-recognition.md). The IVV rules for 20x list July 4, 2026 for optional adoption and obtaining initial certification, and January 1, 2027 for maintaining ongoing certification. Their grace period ends on the first FedRAMP independent assessment started after January 1, 2027. See the [20x IVV applicability notice](https://github.com/FedRAMP/2026-markdown/blob/HEAD/assessors/rules/independent-verification-and-validation.md). For engagement planning, keep those notices next to the relevant rule instead of assigning one date to every assessment obligation. Record whether the discussion concerns an initial certification or an ongoing certification, and check the applicable class and path with the assessor. ## Prepare a short advice record The following is our suggested working record for a provider assessment lead. Adapt it to your team's existing issue tracker or meeting notes. | Field | What to capture | | --- | --- | | Question | The specific uncertainty and the evidence or procedure it concerns. | | Proposed interaction | The advice sought, the people involved, and the intended scope. | | Independence discussion | Concerns raised about objectivity or integrity, prior engagements considered, and any question sent for clarification. | | Advice received | The assessor's recommendation, its date, and the context in which it was given. | | Provider decision | Whether to act on the advice, the reasoning, the owner, and links to changed evidence. | | Assessment conclusion | A reference to the assessor's resulting findings, including any unresolved disagreement. | For example, if a team wants feedback on the clarity of its evidence presentation, describe the requested feedback before the meeting. Afterward, record what was suggested and what the team changed. Treat this as a way to organize the discussion, not as a determination that the interaction meets the independence conditions. Keep advice, implementation decisions, and assessment findings distinguishable in the record. Ask for clarification where a note leaves it unclear whether the assessor offered a suggestion or reached an assessment conclusion. ## Preserve the assessor's findings IVV-IAS-OSA requires the assessor's overall assessment summary to include resulting failures or areas of dispute. IVV-IAS-VIP requires assessors to verify that the provider includes assessment information in the Certification Package without inappropriate modification. See the official [assessor IVV rules](https://github.com/FedRAMP/2026-markdown/blob/HEAD/assessors/rules/independent-verification-and-validation.md). IVV-CSO-ICP likewise requires providers to include independent assessment results in the Certification Package without inappropriate modification. Its note allows presentation or formatting changes while identifying changes to the underlying intent as inappropriate. See [Inclusion in Certification Package](https://github.com/FedRAMP/2026-markdown/blob/HEAD/reference/20x/c/independent-verification-and-validation.md#inclusion-in-certification-package). For your working record, link to the assessor's findings and keep the provider's response separately identifiable. When advice leads to a change, attach the changed evidence and ask how it will be evaluated. Avoid rewriting a finding into a more favorable conclusion yourself. ## Bring a concrete question to the next meeting Choose one open issue and prepare its evidence link, the advice you want, and the prior-engagement facts that may matter. Ask the assessor to discuss the independence implications before expanding the work. If the boundary remains uncertain, capture the unresolved question and seek clarification before proceeding on an assumption. For broader preparation, use our [FedRAMP 20x engineering readiness guide](/blog/20x/engineering-readiness-fedramp-20x) to organize owners and evidence sources for the conversation. ### FedRAMP 20x Vulnerability Reports: Supporting Agency Risk Reviews - URL: https://boundera.io/blog/20x/fedramp-20x-vulnerability-reports-agency-risk-review - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-09-21T14:06:56.430Z - Updated: 2026-09-21T14:13:59Z - Reading time: 6 minutes - Main question: How can a FedRAMP 20x provider prepare vulnerability reports for agency risk reviews? - TL;DR: VER agency guidance uses SHOULD for risk-based review, automated filtering, and agency security-program POA&Ms when relevant under agency policies. We recommend connecting each review decision to the provider finding, any customer mitigation, and a follow-up owner. - Excerpt: Prepare vulnerability report handoffs for agency risk reviews, with review filters, mitigation context, and links to relevant agency POA&M decisions. When preparing vulnerability reports for an agency customer, start with the decision the reviewer needs to make: whether the reported issue changes the risk to that agency's use of your service. Build a clear route from the provider's finding to the agency's review, mitigation decision, and follow-up record. The published FedRAMP Vulnerability Evaluation and Reporting (VER) agency guidance uses SHOULD for risk-based report review, automated processing, and maintaining agency security-program Plans of Action and Milestones (POA&Ms) when relevant under agency policies. [Read the agency guidance](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/agencies/rules/vulnerability-evaluation-and-reporting.md). This guide applies that guidance to a provider preparing for 20x. The suggested handoff fields and example below are our implementation advice. ## Check applicability and adoption dates first The agency guidance applies to agencies using a FedRAMP Certification; its applicability panel lists Class B, Class C, and Class D for the Program and Agency paths, including 20x. The published VER schedule lists optional adoption on July 4, 2026, obtain and maintain dates of December 7, 2026, and a grace end date of March 7, 2027. These are the dates shown in the [official VER source checked on September 21, 2026](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/agencies/rules/vulnerability-evaluation-and-reporting.md). For transition planning, record the applicable class, path, and adoption stage beside your reporting workflow. Keep the December obtain/maintain dates and the March grace date as separate milestones in your plan. FedRAMP defines SHOULD as allowing valid reasons to depart from a rule in particular circumstances, with the implications understood and carefully weighed; parties MUST explain their decisions about handling such rules in their security documentation. [FedRAMP definition of SHOULD](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/definitions.md#should). ## Support a review schedule based on agency risk Under VER-AGM-RVR, agencies SHOULD review vulnerability reports at appropriate, reasonable intervals aligned with the expectations and risk posture in their Authorization to Operate, and SHOULD use automated processing and filtering of machine-readable provider information. [VER-AGM-RVR](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/agencies/rules/vulnerability-evaluation-and-reporting.md#review-vulnerability-reports). For your handoff, ask the customer to identify a review owner and the events that should trigger an earlier review. Record those choices alongside the normal review schedule. Use a stable finding identifier and a clear change summary so a reviewer can compare a new report with the previous one. Keep the agency review schedule distinct from your provider reporting schedule. For 20x providers, VER-TFR-MHR requires reporting vulnerability detection and response activity to all necessary parties in a consistent, human-readable format at least monthly, within the source's stated applicability. [Provider reporting timeframes](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/providers/20x/rules/vulnerability-evaluation-and-reporting.md#monthly-activity-report). ## Preserve the review filter and its exceptions FedRAMP recommends that agencies focus review on overdue and accepted vulnerabilities with a Potential Agency Impact N-rating (PAIN) greater than 2, unless the provider recommends mitigations or the service is part of a higher-risk federal information system. The same note says accepted vulnerabilities generally need review when first added or when a risk assessment is updated because agency use or authorization has changed. [Agency review note](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/agencies/rules/vulnerability-evaluation-and-reporting.md#review-vulnerability-reports). When designing a review view, make the selection logic visible. We suggest recording four reasons an item appears: overdue status, accepted status, provider-recommended mitigation, and higher-risk system context. Let the agency supply its system context, and keep the exception reasons visible even when a rating is low. Do not use that agency review filter to trim your provider reporting feed. VER-RPT-PER requires providers to report vulnerability detection and response activity, including persistent verification and validation, persistently to all necessary parties and to summarize ALL activity since the previous report; those reports are Certification Data subject to Certification Data Sharing rules. [Persistent reporting](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/providers/20x/rules/vulnerability-evaluation-and-reporting.md#persistent-reporting). ## Make the provider report useful for an agency POA&M VER-AGM-MAP says agencies SHOULD use provider vulnerability information to maintain POA&Ms for agency security programs when relevant under their security policies. Its examples include an agency taking action to mitigate exploitation risk or authorizing continued use of a service with accepted vulnerabilities that put agency information systems at risk. [VER-AGM-MAP](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/agencies/rules/vulnerability-evaluation-and-reporting.md#maintain-agency-plans-of-action-and-milestones). For the provider-to-agency handoff, we recommend a compact working record: | Handoff element | Suggested use in the agency review | | --- | --- | | Provider finding identifier and report version | Link the review decision to the precise provider record | | Affected service and customer-use context | Explain which agency workflow the reviewer should examine | | Current rating, status, and change summary | Show what changed since the last review | | Recommended customer mitigation, if any | Give the agency an action to evaluate and assign | | Agency decision, owner, and review date | Record the agency's response separately from provider remediation | | Agency POA&M reference, if relevant | Connect the decision to the agency's own tracking process | Treat this table as a handoff design aid, then reconcile it with the applicable official reporting fields. VER-RPT-VDT requires applicable details for detected vulnerabilities unless they are accepted vulnerabilities, while VER-RPT-AVI separately specifies accepted-vulnerability information, including the provider tracking identifier, current PAIN, and why the vulnerability is accepted. [Provider reporting fields](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/providers/20x/rules/vulnerability-evaluation-and-reporting.md#reporting). ## Walk through a customer review example Consider a hypothetical provider report describing an accepted vulnerability rated N3. For this exercise, suppose the agency uses the affected service in an important workflow and the provider recommends a customer configuration change. We would prepare the handoff in three steps. First, link the report identifier to a short explanation of the affected workflow and the recommended configuration change. Second, ask the agency reviewer to record whether that change is feasible in its environment, who would implement it, and what follow-up evidence would be useful. Third, preserve the agency's decision and any relevant agency POA&M reference alongside the provider's next report. Use the same exercise with a lower-rated item carrying a provider mitigation recommendation. Check that your review view still surfaces the recommendation. Then try an unchanged accepted item, and make sure the interface lets the reviewer distinguish a new finding from a previously reviewed record. The purpose of these exercises is to test your handoff logic. They do not assign an official rating or decide an agency's risk acceptance. ## Prepare the next reporting handoff Choose one recent report and rehearse the agency review with your customer-facing security team. Confirm that a reviewer can find the changed items, understand the filter exceptions, locate the underlying provider records, and record an agency action without rewriting the provider's history. For the broader provider workflow, see our [VDR and POA&M overview](/blog/20x/fedramp-20x-vdr-vs-poam). For this handoff, keep the focus on what the agency needs to evaluate and what your next report should make easy to revisit. ## Frequently asked questions ### Does the agency review filter limit provider reporting? No. VER-RPT-PER requires persistent reporting to all necessary parties summarizing all vulnerability detection and response activity since the previous report, including persistent verification and validation. [Provider rule](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/providers/20x/rules/vulnerability-evaluation-and-reporting.md#persistent-reporting). Apply the agency filter to the review view, while preserving the reporting feed. ### Do agency POA&Ms still matter when a provider moves to 20x? VER-AGM-MAP says agencies SHOULD use provider vulnerability information for agency security-program POA&Ms when relevant according to agency security policies. [Agency POA&M guidance](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/agencies/rules/vulnerability-evaluation-and-reporting.md#maintain-agency-plans-of-action-and-milestones). ### Which VER adoption dates should a transition plan preserve? The published schedule lists July 4, 2026 for optional adoption, December 7, 2026 for obtain and maintain, and March 7, 2027 for the end of grace. [Official schedule](https://github.com/FedRAMP/2026-markdown/blob/cbedf22c86730cfe738a861662f314a2bc0a6ae0/agencies/rules/vulnerability-evaluation-and-reporting.md). ### FedRAMP 20x: Handling Additional Agency Security Requests - URL: https://boundera.io/blog/20x/fedramp-20x-additional-agency-requests - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-09-17T14:08:11.467Z - Updated: 2026-09-17T14:13:30Z - Reading time: 5 minutes - Main question: How should a provider using FedRAMP 20x handle additional agency security requests? - TL;DR: Start by clarifying the requested decision and locating existing evidence. AGU-AGC-NAR excludes clarification and general questions about FedRAMP Certification Data from its restriction on additional materials. For the exception to that restriction, the agency head or authorized delegate must determine a demonstrable need and notify FedRAMP. Use a request record to coordinate the response. - Excerpt: A practical guide to responding to agency questions, identifying additional material requests, and recording the agency decision owner for your 20x offering. When an agency sends your 20x team a security questionnaire or asks for another document, start by identifying what the request adds. Our recommendation is to answer clarification questions from the existing package, identify genuinely additional materials, and keep the agency decision owner involved before committing to new work. This guide explains the agency request rules relevant to providers using 20x, followed by a suggested intake workflow. The workflow and examples are editorial implementation advice, not additional FedRAMP requirements. ## Start with the scope of the agency-use rules The official Agency Use rules list 20x among their applicable certification types. Their effective-date information marks the rules as required under the Consolidated Rules for 2026, with July 4, 2026 listed for obtaining and maintaining certification and the end of the grace period. This article uses that effective-date information, checked on September 17, 2026; it does not treat an RFC proposal or pilot plan as a current obligation. [Agency Use rules and applicability](https://github.com/FedRAMP/2026-markdown/blob/HEAD/agencies/rules/agency-use.md) Keep the agency's authorization work in view. Under AGU-USE-ABU, agencies must complete the Authorization to Operate process for federal information systems that use FedRAMP Certified cloud service offerings. Certification does not replace that agency ATO process. [Authorization Before Use](https://github.com/FedRAMP/2026-markdown/blob/HEAD/agencies/rules/agency-use.md#authorization-before-use) For your team, the practical starting point is a request record: who is asking, what decision they need to make, which offering they mean, and where the relevant evidence already lives. Avoid promising a new assessment or document before that conversation. ## Separate clarification from additional materials AGU-AGC-NAR restricts agencies from requiring information or materials beyond FedRAMP's requirements from a FedRAMP Certified cloud service offering. The exception requires the agency head or an authorized delegate to determine a demonstrable need and notify FedRAMP. The same rule explicitly excludes clarification and general questions about FedRAMP Certification Data from that restriction. [No Additional Security Requirements](https://github.com/FedRAMP/2026-markdown/blob/HEAD/agencies/rules/agency-use.md#no-additional-security-requirements) Use the distinction to guide a conversation, rather than treating certification as a reason to ignore the request. For example, we would initially treat a question asking where an existing package explains a configuration as clarification. We would flag a request to produce a new agency-specific report for closer review. Those are intake examples, not binding classifications; ask the requester what existing information is insufficient and what new work they expect. AGU-AGC-NAI separately requires agencies to notify FedRAMP after requesting additional information or materials beyond FedRAMP's requirements from a FedRAMP Certified offering. Keep that after-request notification duty separate from the demonstrable-need exception in AGU-AGC-NAR. [Notify Additional Information Requests](https://github.com/FedRAMP/2026-markdown/blob/HEAD/agencies/rules/agency-use.md#notify-additional-information-requests) Our advice is to ask the agency contact who owns the determination and notification, then record the response. Do not label your own internal ticket or a provider email as completion of an agency responsibility. ## Handle certification preferences and package conflicts AGU-AGC-TPP restricts agencies from requiring a particular FedRAMP Certification Type or Certification Path. Its exception also requires a demonstrable-need determination by the agency head or an authorized delegate, together with notification to FedRAMP. [No Certification Type or Path Preferences](https://github.com/FedRAMP/2026-markdown/blob/HEAD/agencies/rules/agency-use.md#no-certification-type-or-path-preferences) If a request appears to demand a different type or path, our recommendation is to capture the exact language and ask the agency to identify its decision owner and basis. Avoid committing to a response based on a procurement shorthand phrase alone. There is also an explicit conflict-resolution duty: AGU-USE-RCF requires agencies to collaborate with FedRAMP when agency-specific security determinations conflict with, or reveal discrepancies in, the FedRAMP Certification Package. [Resolve Certification Package Conflicts](https://github.com/FedRAMP/2026-markdown/blob/HEAD/agencies/rules/agency-use.md#resolve-certification-package-conflicts) To support that conversation, prepare a short comparison showing the agency's stated concern, the relevant package passage, and the unresolved difference. Our recommendation is to preserve the original request and evidence version so everyone can discuss the same facts. ## Use a request record before assigning engineering work The following five steps are a suggested operating practice for your 20x team. They do not create a new FedRAMP form, deadline, approval process, or provider reporting obligation. 1. **Capture the request verbatim.** Record the agency contact, date, offering, requested material, requested delivery date, and the decision the material is intended to support. 2. **Find existing evidence.** Link to the exact package section or record that may answer the question. Include its version or date and any limitation that affects the answer. 3. **Describe the gap.** Write down what the request would add: an explanation, a new artifact, a change in certification type or path, or resolution of a conflicting security determination. Leave uncertain cases open for discussion. 4. **Identify the responsible people.** Assign a provider response owner and ask for the agency decision contact. Where the request raises an exception or notification issue, record the agency's explanation and follow-up owner. 5. **Close with a written response.** Summarize the evidence supplied, any additional work agreed, and any unresolved question. Keep the response with the request record for the next conversation. A useful first reply might say: “We have linked the package section that addresses this question. Please confirm whether you need clarification of that information or a new deliverable. If you need a new deliverable, could you identify the remaining gap and the agency contact responsible for the determination?” This is suggested wording, not an official notice template. Use the record to decide what engineering work to schedule. A clearly stated evidence gap and an identified decision owner are better inputs for planning than an unexplained questionnaire attachment. For broader context, see our [guide to getting FedRAMP 20x certified](/blog/20x/how-to-get-fedramp-20x-certified). ## Frequently asked questions ### Can an agency ask questions about an existing certification package? Yes. AGU-AGC-NAR expressly excludes clarification and general questions about FedRAMP Certification Data from its restriction on requiring additional information or materials. Our advice is to answer with a precise evidence reference and explain any remaining gap. [AGU-AGC-NAR](https://github.com/FedRAMP/2026-markdown/blob/HEAD/agencies/rules/agency-use.md#no-additional-security-requirements) ### When does the exception for additional materials apply? Under AGU-AGC-NAR, the head of the agency or an authorized delegate must determine a demonstrable need and notify FedRAMP for the exception to the restriction to apply. AGU-AGC-NAI also requires agency notification after a request for additional information or materials beyond FedRAMP requirements from a FedRAMP Certified offering. [Agency request rules](https://github.com/FedRAMP/2026-markdown/blob/HEAD/agencies/rules/agency-use.md) ### Does certification remove the agency ATO process? No. AGU-USE-ABU requires agencies to complete the Authorization to Operate process for federal information systems using FedRAMP Certified cloud service offerings. [AGU-USE-ABU](https://github.com/FedRAMP/2026-markdown/blob/HEAD/agencies/rules/agency-use.md#authorization-before-use) ### FedRAMP 20x Significant Change Classification: A Decision Guide - URL: https://boundera.io/blog/20x/fedramp-20x-significant-change-classification - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-09-14T14:06:55.883Z - Updated: 2026-09-14T14:15:23Z - Reading time: 6 minutes - Main question: How should a FedRAMP 20x team classify a significant change? - TL;DR: For a significant change, SCN-CSO-EVA checks certification class change first, then routine recurring change, then transformative change, and otherwise adaptive change. Class changes need a new assessment; routine recurring changes are exempt from notification. Apply the 20x transition dates and retain emergency and corrective-action conditions. - Excerpt: A practical guide to classifying changes, documenting the rationale, and replacing the historical draft sequence with current FedRAMP 20x rules. A release ticket says “routine maintenance,” but the proposed work replaces a major component. Before choosing a notification date, write down what changes in the service and why the selected category fits. Use this guide to turn that decision into a reviewable record. ## Scope and effective dates This guide focuses on FedRAMP 20x Class B and Class C providers applying the Consolidated Rules for 2026. The 20x Significant Change Notification page lists July 4, 2026 for obtaining certification and optional adoption, January 1, 2027 for maintaining certification, and the first FedRAMP independent assessment started after January 1, 2027 as the end of the grace period. Apply the relevant transition dates to your offering; publication of the rules does not mean every existing provider has the same immediate deadline. [Check the official applicability and dates](https://www.fedramp.gov/2026/providers/20x/rules/significant-change-notification/). The definitions and rule sequence below are from the current consolidated rules, checked September 14, 2026. RFC-0009 is discussed only as a historical draft comparison. The suggested worksheet and scenarios are our implementation advice, not additional FedRAMP requirements. ## Replace the 2025 draft decision sequence The May 15, 2025 version of RFC-0009 presented draft technical assistance supporting a draft notification standard. It tested routine recurring activity before an impact categorization change and described ongoing operations or vulnerability mitigation and remediation as outside significant changes. That is historical proposal language. [Read the archived draft context](https://www.fedramp.gov/rfcs/0009). The current rules take a different approach. FRD-RTR defines routine recurring change as a type of significant change. SCN-CSO-EVA checks for a certification class change before checking for routine recurring change. It then checks for transformative change, with adaptive change as the remaining category. A certification class change requires a new assessment and cannot proceed under the Significant Change Notification rules. [See the current evaluation rule](https://www.fedramp.gov/2026/providers/20x/rules/significant-change-notification/#evaluate-changes). When updating an old procedure, change both the branch order and the branch names. Avoid a global replacement of “impact categorization” with “certification class”: write a fresh explanation tied to the current definition and the entire offering. ## Compare the four change types FedRAMP defines significant change by reference to NIST SP 800-37 Rev. 2: the change is likely to substantively affect a system’s security or privacy posture. Within that evaluation, use these current definitions. [FedRAMP definitions](https://www.fedramp.gov/2026/definitions/#significant-change). ### Certification class change A certification class change is likely to change the FedRAMP Certification class of the entire cloud service offering, such as Class B to Class C. SCN-CSO-EVA routes that change to a new assessment rather than the notification process. [Definition](https://www.fedramp.gov/2026/definitions/#certification-class-change). ### Routine recurring change A routine recurring change regularly and routinely occurs as part of ongoing operations, vulnerability mitigation, or vulnerability remediation. It remains a significant change type; SCN-RTR-NNR exempts it from notification requirements and says providers SHOULD NOT issue formal Significant Change Notifications for it. [Definition](https://www.fedramp.gov/2026/definitions/#routine-recurring-change) and [notification rule](https://www.fedramp.gov/2026/providers/20x/rules/significant-change-notification/#no-notification-requirements). ### Transformative change A transformative change introduces substantive potential security risks that are likely to affect existing risk determinations and require assessment in depth. The definition notes that such changes typically introduce major features or capabilities and require extensive updates to assessments, procedures, deployment plans, and documentation. [Definition](https://www.fedramp.gov/2026/definitions/#transformative-change). ### Adaptive change An adaptive change does not routinely recur and does not introduce substantive potential security risks that need assessment in depth. The definition describes changes typically focused on engineering execution, with minor adjustments to existing automated validation procedures and no large changes to operational procedures, deployment plans, or documentation. [Definition](https://www.fedramp.gov/2026/definitions/#adaptive-change). ## Record the decision before scheduling notifications SCN-CSO-EVA requires providers to evaluate all potential significant changes and follow the rules for the selected type. SCN-CSO-MAR requires auditable records of that evaluation, available to FedRAMP on request. Its note says those records do not need to be included in the certification package by default or emailed continuously. [Evaluation and audit record rules](https://www.fedramp.gov/2026/providers/20x/rules/significant-change-notification/#maintain-audit-records). Our suggested worksheet has six fields. Use it inside your existing change process and link the supporting evidence: 1. **Change description:** Capture the before and after state, affected components, and customer responsibilities. 2. **Significance rationale:** Explain the expected effect on security or privacy. 3. **Class assessment:** Record whether the entire offering is likely to change certification class. 4. **Category rationale:** Explain regular recurrence, or the depth of security risk assessment needed. 5. **Evidence and owner:** Link the engineering analysis and identify the person responsible for the decision. 6. **Follow-through:** Record the applicable notification path, exceptions, and work needed to verify the implemented change. Keep the internal worksheet distinct from a notification. SCN-CSO-INF requires a notification to include at least the offering’s FedRAMP ID; assessor and related vulnerability where applicable; category and justification; description and reason; customer impact and configuration responsibilities; a plan and timeline covering relevant verification, assessment, or validation; the business or security impact analysis; and the approver’s name and title. [Required notification information](https://www.fedramp.gov/2026/providers/20x/rules/significant-change-notification/#required-information). ## Work through examples without automatic labels These scenarios illustrate our suggested reasoning process. They are conditional applications of the definitions, not official classifications of a named technology. **A familiar patch through an established release process.** Start by documenting whether this is genuinely regular, recurring work. If the patch instead needs an unusual migration or a redesign, reopen the classification. Do not let the word “patch” decide the outcome. **A one-time component replacement.** Compare data flows, privileges, customer responsibilities, and validation coverage before and after the replacement. If your analysis supports a nonrecurring change without substantive new security risks needing assessment in depth, document the reasoning for adaptive treatment. If those conditions are not supported, continue the risk analysis. **A new capability handling customer data differently.** Ask which existing risk determinations still hold and what needs assessment in depth. Use that analysis to evaluate transformative treatment, after checking whether the entire offering’s certification class is likely to change. A product launch label alone is insufficient evidence for the decision. For a useful internal review, ask a colleague to explain the category from the evidence without reading the release ticket’s original label. Revise the rationale wherever they cannot follow the decision. ## Apply the notification path and its exceptions For providers applying these rules, SCN-ADP-NTF requires notification to all necessary parties within 10 business days after finishing adaptive changes, including new risks or resulting vulnerabilities where applicable. Routine recurring changes have the notification exemption described above. [Adaptive notification rule](https://www.fedramp.gov/2026/providers/20x/rules/significant-change-notification/#notification-requirements). For transformative changes, SCN-TRF-NIP and SCN-TRF-NFP require initial-plan notification at least 30 business days before starting and final-plan notification at least 10 business days before starting. SCN-TRF-NAF requires notification within five business days after finishing; SCN-TRF-NAV separately requires notification within five business days after completing verification, assessment, and/or validation. Each goes to all necessary parties, with the information specified by the applicable rule. [Transformative notification rules](https://www.fedramp.gov/2026/providers/20x/rules/significant-change-notification/#transformative-changes). Keep two exceptions visible in the procedure. Under SCN-CSO-EMG, emergency or incident changes, including transformative changes, may proceed without advance compliance with notification rules. Providers must still follow relevant procedures, notify all necessary parties, supply the notification materials retroactively, and complete appropriate assessment after the incident. Under SCN-FRP-CAP, FedRAMP may require a longer delay or advance approval as a condition of a formal corrective action plan or other agreement. [Emergency rule](https://www.fedramp.gov/2026/providers/20x/rules/significant-change-notification/#emergency-changes) and [corrective action conditions](https://www.fedramp.gov/2026/reference/significant-change-notification/#corrective-action-plan-conditions). Before scheduling a release, put the applicable category, transition date, and any emergency or corrective-action conditions beside the implementation timeline. Assign owners to the follow-up steps so a completed deployment does not close the decision record prematurely. ### FedRAMP VDR and VER: What CSPs Must Do Before December 7, 2026 - URL: https://boundera.io/blog/20x/fedramp-vdr-ver-december-2026-deadline - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP Guides - Published: 2026-08-13T12:00:00.000Z - Updated: 2026-08-19T04:28:57Z - Reading time: 7 minutes - Main question: What is the December 7, 2026 FedRAMP VDR and VER deadline? - TL;DR: FedRAMP Notice NTC-0014 makes the Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rulesets mandatory on December 7, 2026 for every certified or in-process cloud service offering, Rev 5 and 20x alike, with certification revocable after March 7, 2027. Remediation deadlines now come from certification class, potential agency impact, internet-reachability, and exploitability instead of scanner severity. - Excerpt: CISA BOD 26-04 flows down to every FedRAMP provider through Notice NTC-0014: the VDR and VER rulesets become mandatory on December 7, 2026, and monthly scanning no longer satisfies them. If you hold a FedRAMP certification, or you are working toward one, you have a hard deadline on **December 7, 2026**. On that date the Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rulesets become mandatory for every cloud service offering. This applies whether you are on Rev 5 or 20x. The grace period ends **March 7, 2027**. After that, FedRAMP can revoke certification for providers that have not transitioned. This is not a 20x-only change. If you are a Rev 5 provider running monthly authenticated scans and filing a POA&M, FedRAMP has said directly that this process is insufficient. ## Where the deadline came from The chain runs from CISA to FedRAMP to you. On June 10, 2026, CISA issued [Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk). BOD 26-04 supersedes and revokes BOD 19-02 and BOD 22-01. It replaces severity-driven patching with risk-based prioritization built on exposure, known exploitation, automatability, and technical impact. On June 16, 2026, FedRAMP published [Notice NTC-0014, FedRAMP Response to CISA BOD 26-04](https://www.fedramp.gov/notices/0014/). The notice sets the December 7 date and names the two rulesets that carry the directive down to providers: VDR and VER. The logic is straightforward. Agencies must now prioritize remediation by risk under BOD 26-04. Agencies cannot do that for the services they consume unless providers supply the evaluation data behind it. A monthly scan report does not contain that data. ## What each ruleset covers The two rulesets split the work. **VDR (Vulnerability Detection and Response)** covers finding vulnerabilities and doing something about them: detection coverage, cadence, response, and remediation timeframes. There are 17 requirements. **VER (Vulnerability Evaluation and Reporting)** covers judging what you found and telling people about it: exploitability, internet-reachability, potential agency impact, and the reports that go to agencies and FedRAMP. There are 23 requirements. Together they replace the operating model most providers run today. ## The three evaluations you must perform The center of the change is VER. Every detected vulnerability now needs three judgments before you can decide how fast to fix it. | Evaluation | Rule | Question it answers | | --- | --- | --- | | Internet-reachability | [VER-EVA-EIR](/fedramp-20x/rules/ver/eva-eir) | Can it be reached from the internet? | | Exploitability | [VER-EVA-ELX](/fedramp-20x/rules/ver/eva-elx) | Is it likely exploitable? | | Potential Agency Impact | [VER-EVA-EPA](/fedramp-20x/rules/ver/eva-epa) | How badly would exploitation hurt your agency customers? | All three are MUST requirements. Scanner severity does not satisfy any of them, because none of them is a property of the vulnerability alone. Each depends on where the vulnerability sits in your boundary and who your customers are. Potential Agency Impact uses a five-level scale called PAIN: - **N1**: minimal customer effects on one or more agencies - **N2**: narrow customer effects on one or more agencies - **N3**: a disruptive customer effect on one agency - **N4**: a debilitating customer effect on one agency, or a disruptive effect on more than one - **N5**: a debilitating customer effect on more than one agency ## Remediation timeframes are now a matrix Under the old model, remediation deadlines came from severity: 30 days for high, 90 for moderate, 180 for low. Under [VDR-TFR-PVR](/fedramp-20x/rules/vdr/tfr-pvr), the deadline is a function of your certification class, the PAIN rating, internet-reachability, and exploitability. Here is the fastest lane, an internet-reachable and likely exploitable vulnerability, across classes: | PAIN | Class A | Class B | Class C | Class D | | --- | --- | --- | --- | --- | | N5 | 4 days | 4 days | 2 days | 12 hours | | N4 | 8 days | 8 days | 4 days | 2 days | | N3 | 32 days | 32 days | 16 days | 8 days | | N2 | 96 days | 96 days | 48 days | 24 days | Two things stand out. A Class D provider with a critical internet-reachable flaw has twelve hours, which no monthly process can meet. And a not-likely-exploitable N2 finding gets 192 days at Class A, far longer than the old 30-day clock for a "high" severity. That second point matters as much as the first. Risk-based prioritization is not only about moving faster. It is about not burning your engineering capacity on findings that do not threaten your agency customers. ## Detection cadence is now explicit Detection has its own clocks, and they also vary by class. | Requirement | Class A | Class B | Class C | Class D | | --- | --- | --- | --- | --- | | [Persistent Drift Detection](/fedramp-20x/rules/vdr/tfr-pdd) | 3 months | 1 month | 14 days | 7 days | | [Persistently Complete Detection](/fedramp-20x/rules/vdr/tfr-pcd) | 6 months | 6 months | 1 month | 1 month | | [Evaluate Vulnerabilities Quickly](/fedramp-20x/rules/ver/tfr-evu) | 14 days | 7 days | 5 days | 2 days | Note the third row. Evaluation is on a clock of its own. Finding a vulnerability and sitting on it for a month before rating it fails VER independently of whether you remediate on time. ## Known Exploited Vulnerabilities get their own rule [VDR-TFR-KEV](/fedramp-20x/rules/vdr/tfr-kev) says providers should remediate Known Exploited Vulnerabilities according to the due dates in the CISA KEV catalog, as required by BOD 26-04, **even if the vulnerability has been fully mitigated**. That last clause is the part teams miss. A compensating control that removes exploitability does not stop the KEV clock. There is also a companion rule, [VDR-CSO-AKE](/fedramp-20x/rules/vdr/cso-ake), on avoiding KEVs in the first place. ## Reporting changes shape Under [VER-RPT-PER](/fedramp-20x/rules/ver/rpt-per), reporting becomes persistent: providers must report detection and response activity to all necessary parties continuously, summarizing all activity since the previous report. A human-readable summary is still required at least monthly under [VER-TFR-MHR](/fedramp-20x/rules/ver/tfr-mhr). The monthly artifact does not disappear. What changes is that it becomes a summary of a continuous process rather than the process itself. ## What this means if you are on Rev 5 today This is the group most at risk of missing the deadline, because nothing about it feels like a 20x project. Your current process probably looks like this: authenticated scans once a month, results triaged by CVSS score, findings tracked in a POA&M with 30/90/180-day deadlines, and a monthly package to your agency. Against the new rules, four gaps show up: 1. **No exploitability or reachability evaluation.** CVSS is a severity score, not a determination of whether the flaw is reachable in your boundary or likely to be exploited. 2. **No agency-impact rating.** PAIN has no equivalent in the Rev 5 workflow. 3. **Deadlines from the wrong input.** Severity-derived due dates will be both too slow for genuinely dangerous findings and too aggressive for harmless ones. 4. **Cadence gaps.** Monthly detection cannot satisfy drift detection at Class C or D, and evaluation has its own clock regardless of class. ## A practical sequence between now and December 7 You do not need to solve all 40 requirements at once. The dependencies run in one direction, so work in this order. 1. **Inventory your detection coverage.** [VDR-CSO-DET](/fedramp-20x/rules/vdr/cso-det) requires systematic, persistent, prompt discovery across the offering. Find the resources nothing currently scans. 2. **Add the three evaluations to your pipeline.** Reachability, exploitability, and PAIN. Until these exist, no correct remediation deadline can be computed. 3. **Recompute your due dates.** Replace severity-derived deadlines with the PVR matrix for your class. 4. **Wire the KEV catalog in.** Due dates come from CISA, not from you, and they apply to mitigated findings too. 5. **Fix the cadence.** Match drift and complete-detection intervals to your class. 6. **Convert reporting.** Move from a monthly artifact to persistent reporting with a monthly human-readable summary on top. 7. **Handle accepted vulnerabilities.** [VER-TFR-MAV](/fedramp-20x/rules/ver/tfr-mav) and [VER-RPT-AVI](/fedramp-20x/rules/ver/rpt-avi) govern what you must record and disclose when a vulnerability is accepted rather than fixed. ## The part that is easy to underestimate The evaluations are per-vulnerability, continuous, and auditable. Three judgments on every finding, forever, each one defensible to an assessor. For a small provider with a few hundred findings a month, that is a meaningful analyst workload. For a larger boundary it is not something a team does by hand. This is why the rules repeatedly point toward automation, and why [VER-EVA-AIA](/fedramp-20x/rules/ver/eva-aia) ("Assume It's Automatable") is a MUST rather than a suggestion. Boundera evaluates reachability, exploitability, and potential agency impact automatically from connected evidence, computes remediation deadlines from your certification class, and produces the persistent reporting VER requires. If you want to see where you stand against these 40 requirements first, the [free gap assessment](/fedramp-gap-assessment) scores your readiness in about five minutes. ## Key dates - **June 10, 2026**: CISA issues BOD 26-04 - **June 16, 2026**: FedRAMP publishes NTC-0014 - **December 7, 2026**: VDR and VER become mandatory for all certified and in-process offerings - **March 7, 2027**: grace period ends; certification may be revoked for non-compliance ## References - [FedRAMP Notice NTC-0014: FedRAMP Response to CISA BOD 26-04](https://www.fedramp.gov/notices/0014/) - [CISA BOD 26-04: Prioritizing Security Updates Based on Risk](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk) - [Vulnerability Detection and Response rules (VDR)](/fedramp-20x/rules/vdr) - [Vulnerability Evaluation and Reporting rules (VER)](/fedramp-20x/rules/ver) - [VDR vs POA&M: how the operating model changes](/blog/20x/fedramp-20x-vdr-vs-poam) ### FedRAMP 20x SSP Automation: What Still Matters After Control Narratives - URL: https://boundera.io/blog/20x/fedramp-20x-ssp-automation-control-narratives - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-07-27T19:25:47.049Z - Updated: 2026-08-02T19:35:20Z - Reading time: 1 minutes - Main question: What still matters when FedRAMP package work becomes more automated? - TL;DR: The important thing is not that every package looks identical; the important thing is that the required information is accurate, current, understandable, and available in both human-readable and machine-readable forms when required. - Excerpt: A 20x package is a set of FedRAMP Certification Data that a cloud service provider maintains over time and shares with FedRAMP, agencies, and other necessary parties. ## What Still Matters A 20x package is a set of FedRAMP Certification Data that a cloud service provider maintains over time and shares with FedRAMP, agencies, and other necessary parties. The package may be presented through a provider trust center, a documentation portal, downloadable files, APIs, or a combination of these. ## What Automation Has To Preserve The important thing is not that every package looks identical; the important thing is that the required information is accurate, current, understandable, and available in both human-readable and machine-readable forms when required. For a team moving away from control-narrative-first work, the point is not to delete explanation. The point is to keep explanation tied to package data that can stay current. ## Operating Checklist Use the package as the organizing unit: identify what must stay accurate, decide where each item is maintained, and make the human-readable view traceable to the machine-readable material when required. ## Takeaway Automation helps most when it keeps the package accurate and reviewable over time. Static narratives matter less than current package data that the right parties can inspect and reuse. ### FedRAMP 20x KSI Evidence Workflow: Verification, Validation, and History - URL: https://boundera.io/blog/20x/fedramp-20x-ksi - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-07-13T14:04:05.825Z - Updated: 2026-08-02T19:35:20Z - Reading time: 5 minutes - Main question: How should a CSP turn FedRAMP 20x KSI requirements into a reviewable evidence workflow? - TL;DR: Treat each indicator as a repeatable evidence workflow with implementation proof, effectiveness proof, automation, and retained history. - Excerpt: A practical guide to turning outcome indicators into reviewable evidence, automation, and retained history. # FedRAMP 20x KSI Evidence Workflow: Verification, Validation, and History Teams usually get stuck after the rule page: they know the indicator exists, but not what a reviewer needs to see. Official package guidance says a 20x package includes summaries and measures showing how the cloud service provider demonstrates important security outcomes across the FedRAMP 20x Key Security Indicators. ## What The Workflow Has To Prove Assessor guidance says a Key Security Indicator is an outcome claim and that the provider decides how to measure it. That is the useful starting point for an evidence workflow article. A team has to show the security capability itself, the data used to evaluate it, and the logic that turns that data into a result. Family-by-family detail belongs in a separate surface from the operational evidence workflow. ## Separate Implementation Proof From Effectiveness Proof Independent Verification and Validation rules say providers must supply evidence of implementation to assessors, and that evidence is the result of verification. The same rules say providers must also supply evidence of effectiveness to assessors, and that evidence is the result of validation. That split is the easiest way to keep the workflow honest. Implementation evidence answers what was configured or deployed. Effectiveness evidence answers whether the expected outcome happened when the system ran. Use live demonstrations, direct queries, machine-readable results, and historical trends whenever they give a stronger answer than a static export. ## Build One Evidence System For Humans And Machines Certification Data Sharing rules say providers must use automation to keep information consistent between human-readable and machine-readable formats when the same FedRAMP Certification Data is provided in both formats. The same rules say trust centers must provide documented programmatic access to all FedRAMP Certification Data, including human-readable materials. Official package guidance says a 20x package is a set of FedRAMP Certification Data that a provider maintains over time and can present through a trust center, documentation portal, downloadable files, APIs, or a combination of those surfaces. In practice, that means one maintained source record should feed the portal page, the downloadable artifact, and any machine-readable output. If teams hand-edit multiple surfaces, drift becomes normal instead of exceptional. ## What A Reviewable Workflow Should Include Certification Data Sharing rules say providers must include human-readable and machine-readable references for relevant policies and procedures, including the policy or procedure name, source file or page, summary, word count, current version, and last update date. Assessment guidance also says providers should keep the human-readable explanation tied to the machine-readable evidence. A practical workflow usually needs five parts: 1. A scoped inventory of the systems, services, and data that the indicator covers. 2. The exact query, code path, or human procedure that produces the result. 3. Clear failure criteria and an owner for follow-up when the result changes. 4. Evidence links that preserve enough context for a reviewer to reproduce the conclusion. 5. Retained snapshots or history that show whether the result is stable over time. ## Why History And Cadence Matter FedRAMP 20x certification rules say providers seeking 20x Class C certification must implement automated methods to persistently verify and validate the accuracy and completeness of Key Security Indicators with at least two automated methods for each indicator. The same certification rules say providers seeking 20x Class C certification must supply historical metrics, including status from persistent validation, for all Key Security Indicators over at least the past six months. Independent assessment rules say providers with 20x Class C certifications must include all Key Security Indicators in a FedRAMP independent assessment at least once per year. That is why this topic is not just about writing cleaner summaries. The operating model has to preserve current results, prior results, and the method that produced both. ## The Practical Takeaway The safest way to approach this topic is to treat each indicator as a repeatable evidence product, not as a one-time documentation task. If a reviewer cannot trace the result back to current source data, the workflow is not ready. If the same data cannot feed both the human explanation and the machine-readable output, the workflow will be hard to keep current. ## FAQ ### What proves readiness? Current source data, repeatable validation, and retained history prove more than a one-time export. ### What should teams automate first? Automate the fields and checks that already appear in multiple outputs, then connect them to evidence links, ownership, and failure handling. ### Why keep past results? Historical results make it easier to explain drift, show cadence, and answer reviewer questions without rebuilding the story from scratch. ### FedRAMP 20x vs Rev 5: KSI Validation vs Control Narratives - URL: https://boundera.io/blog/20x/fedramp-20x-vs-rev5-ksi-validation-control-narratives - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-07-09T14:12:00.000Z - Updated: 2026-08-02T19:35:20Z - Reading time: 7 minutes - Main question: What is the practical difference between FedRAMP 20x KSI validation and Rev5 control narratives? - TL;DR: In 2026, both paths use the SDR. The difference is that 20x summarizes how KSIs are measured and validated, while Rev5 summarizes how controls are implemented, verified, and validated. - Excerpt: FedRAMP 20x centers the SDR on KSI validation summaries, while Rev5 keeps control-by-control implementation summaries. ## Short answer If you strip away old SSP habits, the current difference is not "20x has no writing and Rev5 has all the writing." The 2026 20x materials say the Security Decision Record (SDR) replaced the traditional System Security Plan. The current Rev5 package materials make the same shift. The split is what that record is centered on. In 20x, the SDR must summarize each applicable Key Security Indicator (KSI): the measure, its objective, the cycle for persistent measures, how the measure is verified, whether the automation is accurate enough, and how the measure is validated. In Rev5, the SDR must summarize each applicable control: parameter values, implementation status, the mechanisms or activities that address the control, and the verification and validation tied to that control. That is why "KSI validation vs control narratives" is the right framing for 2026. The 20x path is built around proving security outcomes through measurable validation. The Rev5 path still asks you to explain control implementation in a control-by-control way, even though it also expects verification, validation, and current evidence. ## What FedRAMP 20x is trying to get from you FedRAMP's 20x guidance says the certification rules replace long traditional narrative descriptions and web pages with simple declarative statements. That is a meaningful shift in authoring style. The goal is not to produce less thought. The goal is to make the package easier to follow rule by rule and easier to connect to current evidence. The KSI guidance is even clearer about the operating model. It says security controls define required protections, but Key Security Indicators provide measurable validation that those protections are functioning properly within operational environments. In other words, a 20x reviewer is not mainly looking for a long description of your intent. They are looking for a summary of the measures that demonstrate the outcome and the evidence that those measures are still true. The 20x SDR rules make that concrete. For each applicable KSI, the provider must include short, simple high-level summaries of: - The measures and objectives that demonstrate the KSI - The cycle for persistently implemented measures - Verification that the measures demonstrate the KSI - Verification that the automation is accurate and sufficient, or an explanation of why automation is not necessary - Validation that the measures are accurately produced and working as intended That structure is why 20x feels different in practice. The writing is still there, but it is subordinate to the validation system. You are summarizing how the outcome is measured and checked, not building a long narrative that has to stand in for the check. ## What Rev5 still wants you to explain Rev5 starts from a different unit of organization. The official controls guidance says FedRAMP Rev5 uses controls from NIST SP 800-53 Revision 5 as the detailed security and privacy requirements for cloud service offerings. It also says those controls are grouped into families such as Access Control, Configuration Management, Incident Response, Risk Assessment, and System and Information Integrity. That matters because a Rev5 package is still organized around those control statements. The controls page explicitly tells providers to connect each control to real system behavior: what risk the control addresses, where the activity happens, what safeguards implement it, who owns it, what evidence demonstrates it, and how it continues to work over time. That is much closer to what most teams mean when they say "control narratives." The Rev5 SDR rules preserve that orientation. For each applicable Rev5 control, providers must include short and simple high-level summaries covering: - Organization-defined parameter values - Implementation status - The mechanisms or activities that address the control, including inheritance when applicable - The verification in place to ensure the implementation is appropriate for the control - The validation in place to ensure the implementation is working as intended - Independent verification and independent validation - Control-specific artifacts when applicable So Rev5 is not just "write prose." It is still evidence-backed. But the prose burden is attached to each control, which keeps the package more narrative and more control-centered than the 20x KSI model. ## Where the two paths are more similar than people assume The cleanest 2026 correction is that both paths now point to the Security Decision Record. The 20x package materials say the SDR replaced a traditional SSP with a persistently maintained, verified, and validated record of security decisions. The Rev5 package materials say the same thing. That does not mean the two paths are identical. It means the old mental model of "Rev5 equals giant SSP, 20x equals no package" is out of date. Both paths now expect structured, maintained records. The difference is the focal point inside that record: KSI summaries for 20x, control summaries for Rev5. The independent verification and validation rules narrow the gap further. They require providers to supply evidence of implementation to assessors as the result of verification, and evidence of effectiveness as the result of validation. That language matters because it applies the same evidence discipline to the package regardless of path. A control narrative without proof is weak. A KSI summary without proof is weak. FedRAMP's assessor update for 2026 makes the same point from the review side. Under Program Certification, assessors are expected to verify and validate the FedRAMP practices employed by the provider instead of just determining whether the provider meets the control. That is not a license to ignore Rev5 controls. It is a reminder that even on the Rev5 path, the end state is not supposed to be a pile of persuasive writing disconnected from current operations. ## How to use this difference when planning your package If you are designing for 20x, your writing should stay thin and operational. The hard work is defining the measure, the objective, the evidence cycle, and the validation loop for each KSI. If your team spends more energy polishing paragraphs than proving the KSI from live systems, you are optimizing the wrong thing. If you are designing for Rev5, you still need good narratives, but the best narratives are compact explanations of real implementation. The official controls guidance says the strongest control narratives come from actual engineering and operations practices. That is the right standard. A Rev5 narrative should explain a real mechanism and point to real evidence, not compensate for weak operations. If you need one internal operating model that can support both paths, treat evidence collection as the shared layer and treat package writing as the view layer. Build one evidence system that can show current implementation, current effectiveness, ownership, and artifacts. Then generate a KSI-oriented summary for 20x and a control-oriented summary for Rev5 from that same source of truth. ## Bottom line FedRAMP 20x and Rev5 now share more package mechanics than the older blog-era shorthand suggests. Both use the SDR. Both require human-readable and structured information. Both require verification, validation, and independent review. But they still ask different top-level questions. Rev5 asks you to explain how each control is implemented and maintained. 20x asks you to summarize the measures that demonstrate each KSI and prove that those measures are being verified and validated over time. That is the practical difference between KSI validation and control narratives in 2026. ## Frequently asked questions ### Does FedRAMP 20x eliminate writing? No. The 20x path still requires human-readable summaries in the Security Decision Record. What changes is the center of gravity: the writing summarizes measures, persistence, verification, automation sufficiency, and validation for each KSI instead of carrying the package by itself. ### Does Rev5 still need current evidence if it keeps control narratives? Yes. The current rules require evidence of implementation for verification and evidence of effectiveness for validation. Rev5 still allows a more control-centered narrative structure, but the narrative is supposed to describe real mechanisms and current evidence. ### What is the simplest way to explain the difference to an engineering team? Tell them that 20x is outcome-first and Rev5 is control-first. In 20x, the package summary should explain how a KSI is measured and validated. In Rev5, the package summary should explain how a control is implemented, verified, and validated. ### FedRAMP 20x OSCAL Evidence Automation: A Practical Workflow - URL: https://boundera.io/blog/20x/fedramp-20x-oscal-evidence-automation - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-07-06T14:08:39.215Z - Updated: 2026-08-02T19:35:20Z - Reading time: 6 minutes - Main question: How should teams build a FedRAMP 20x OSCAL evidence automation workflow? - TL;DR: A 20x package is a set of FedRAMP Certification Data that a cloud service provider maintains over time and shares with FedRAMP, agencies, and other necessary parties. - Excerpt: FedRAMP's 20x certification rules say providers must supply machine-readable information in JSON documents whenever a rule includes a FedRAMP JSON schema. # FedRAMP 20x OSCAL Evidence Automation: A Practical Workflow FedRAMP's 2026 Agency Use rules say agency governance, risk, compliance, and inventory tools must produce and ingest machine-readable artifacts in at least OSCAL and JSON. FedRAMP's 20x certification rules say providers must supply machine-readable information in JSON documents whenever a rule includes a FedRAMP JSON schema. ## Start With The Real Package Model FedRAMP's agency guidance says a 20x package is a maintained set of FedRAMP Certification Data, not a static folder of documents. The same guidance says that package may be presented through a trust center, documentation portal, downloadable files, APIs, or a combination of those surfaces. That matters because evidence automation is really package automation: one workflow producing current certification data for multiple consumers. In practice, that means your source systems matter more than your final file format. Boundary records, inventory, policy references, validation results, and assessor-facing summaries should be generated from controlled records that can be refreshed on demand. If those records drift, an OSCAL export will drift with them. ## What The Workflow Must Prove FedRAMP's 20x independent verification and validation rules say providers must supply evidence of implementation to assessors. The same rules separately say providers must supply evidence of effectiveness to assessors. That is the line between structured documentation and actual evidence automation. A strong workflow makes those two evidence types easy to distinguish. Implementation evidence shows what you configured or deployed. Effectiveness evidence shows whether the control outcome is actually happening in the running service. For example, a policy file or firewall rule proves less than a current validation result tied back to the same control objective. ## Keep Policies, Procedures, And Evidence References In One System FedRAMP's 20x certification-data-sharing rules say providers must include relevant policies and procedures in certification data with both human-readable and machine-readable references. The same rule says each reference has to explain at least the policy or procedure name, the source file or page, a brief summary, word count, current version, last update date, and related FedRAMP practices when applicable. That requirement is a useful design hint. Do not treat policies as detached attachments and evidence as a separate spreadsheet. Keep policy references, control or KSI mappings, validation ownership, and evidence links in one model so the package can answer basic reviewer questions without manual reconciliation. ## Keep Human-Readable And Machine-Readable Outputs In Sync FedRAMP's 20x certification-data-sharing rules require automation when the same certification data is available in both human-readable and machine-readable formats. The trust-center rules also say trust centers should make certification data available to view and download in both formats. That combination pushes teams toward a simple architecture: one source record, multiple renderers. Your human-readable page, JSON output, and OSCAL artifact should come from the same controlled records instead of from separate editing workflows. That is the only practical way to reduce drift as the service, evidence, or package status changes. ## Where OSCAL Fits It is one of the formats agencies are required to support in their internal tooling. It also works well as a structured output for implementation and assessment content. But OSCAL is best treated as one output of the evidence pipeline, not as the pipeline itself. ## Class C Raises The Bar FedRAMP's 20x certification rules say providers seeking Class C certification must supply at least six months of historical KSI metrics, including status from persistent validation. Once that requirement is in scope, retained history, timestamps, and prior results stop being optional. You need enough context to explain changes over time. If your workflow cannot preserve history, it will not be ready for a Class C review. ## A Practical Minimum Workflow 1. Define the authoritative systems for boundary, inventory, policy references, validation results, and evidence links. 2. Map each output field in your JSON and OSCAL artifacts back to one maintained source record. 3. Separate implementation evidence from effectiveness evidence so assessors can see both verification and validation clearly. 4. Render human-readable package views from the same records that generate machine-readable outputs. 5. Preserve timestamps and historical validation state early, especially if Class C is the target. That workflow is more useful than a one-time conversion project because it keeps the package current after engineering changes, control updates, and assessment findings. ## FAQ ### What proves readiness? Current evidence, timestamps, retained history, and reviewer-readable outputs prove more than a one-time export. ### What should teams automate first? Start with the fields that appear in both human-readable and machine-readable outputs, then connect those records to current validation evidence. That usually means boundary facts, inventory, policy references, ownership, timestamps, and the evidence links that explain why a result passed or failed. ### How to Track FedRAMP 20x Changes Before They Affect Your Authorization Plan - URL: https://boundera.io/blog/20x/fedramp-20x-change-tracking-authorization-plan - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-07-02T19:58:52.252Z - Updated: 2026-08-02T19:35:20Z - Reading time: 6 minutes - Main question: How should CSPs track FedRAMP 20x changes before they affect an authorization plan? - TL;DR: Build a weekly workflow that reviews official FedRAMP changelog, notice, and rule updates, classifies impact, and sends possible significant changes to the right owner before implementation starts. - Excerpt: FedRAMP 20x updates need a lightweight workflow that turns official changelog, notice, and rule changes into clear authorization-plan decisions. FedRAMP 20x is moving quickly enough that "check the website once a quarter" is no longer a real operating model. The practical question is not whether FedRAMP will change again. It will. The question is how your team will notice the change, classify it, and decide whether it affects your authorization plan before it turns into rushed evidence work. FedRAMP publishes a 2026 changelog for summaries of release changes made after June 23, 2026. The changelog says FedRAMP intends to minimize changes to the Consolidated Rules, but may still update the rules or site content for typos, confusion, or urgent critical updates. That is enough to justify a lightweight change-tracking workflow. You do not need a new governance committee for every typo. You do need a repeatable way to separate "FYI" updates from changes that should hit your package, customer communication, engineering roadmap, or assessment plan. ## Watch the sources that can change the plan Start with three official inputs: the FedRAMP 2026 changelog, official notices, and the 2026 rules or guidance pages that apply to your certification path. Competitor explainers can help you spot market confusion, but they should not be the source of truth for FedRAMP requirements. The July 1, 2026 FedRAMP 2026 changelog entry says that release included minor enhancements and fixes, with no significant changes to requirements. That is a good example of an update that still deserves review, because even non-requirement changes can rename schema files, clarify applicability, or fix wording that your internal references depend on. Your tracking log should capture four fields for each official update: 1. What changed in FedRAMP's source material. 2. Whether the change affects your current certification path, class, package, or customer use case. 3. Which internal owner needs to review it. 4. Whether the action is documentation-only, engineering-impacting, customer-facing, or no action. That small amount of structure is what keeps a changelog review from becoming another unread compliance inbox. ## Classify updates before assigning work Not every FedRAMP update creates the same type of internal task. A schema rename may affect automation. A notification rule may affect customer communications. A certification path clarification may affect executive planning. FedRAMP says providers already invested in the legacy FedRAMP Certification process need to understand changes and adjust to the FedRAMP Consolidated Rules for 2026 as quickly as possible. FedRAMP also says every cloud service provider will need to adjust processes, tools, capabilities, and methodologies to retain FedRAMP Certification. That does not mean every update becomes a fire drill. It means each update needs triage. A useful first-pass classification is: - **Reference update:** update links, field names, glossary language, or internal training notes. - **Package update:** change the Certification Package Overview, Security Decision Record, customer-facing evidence, or source data. - **Operating update:** change how engineering, vulnerability response, incident handling, or change management work is performed. - **Customer update:** notify agencies or other necessary parties because the change affects risk, configuration, service behavior, or certification data. If an update does not fit one of those buckets, record why it was closed with no action. That audit trail is useful later when a customer asks why the team did not react to a public FedRAMP update. ## Connect change tracking to significant-change rules The most important operational handoff is between policy monitoring and significant-change evaluation. For 20x Class C, FedRAMP rules say providers must evaluate all potential significant changes to determine the type of significant change and follow the appropriate Significant Change Notification rules. FedRAMP rules also say providers must maintain auditable records of significant-change evaluation activities and make them available to FedRAMP on request. That means your FedRAMP update log should not live separately from your engineering change process. When an official update touches service behavior, security responsibilities, customer configuration, assessment scope, or evidence format, the reviewer should decide whether it creates or modifies a significant-change evaluation. For example, an update that only fixes a typo in FedRAMP guidance may close as a reference update. An update that changes how a provider must describe customer impact should probably be checked against notification templates and customer communication procedures. ## Use timing rules to avoid last-minute scramble FedRAMP's significant-change categories give you a practical timing model. For adaptive changes, 20x Class C rules say providers must notify all necessary parties within 10 business days after finishing adaptive changes. For transformative changes, 20x Class C rules say providers must notify all necessary parties of initial plans at least 30 business days before starting transformative changes. Those timing differences matter. If you wait until implementation is done to classify the change, you may already have missed the planning window for a transformative change. The safer pattern is to run a short weekly review: 1. Check the official changelog and notices. 2. Review any FedRAMP source files or pages tied to your path and class. 3. Compare updates against open engineering and GRC work. 4. Escalate anything that might affect customer impact, service scope, assessment scope, or certification data. 5. Close the loop with a written no-action, monitor, or action-required decision. This is deliberately boring. Boring is the point. A calm weekly habit beats a panicked Friday search through release notes. ## Make the output useful for agencies Agencies are not passive recipients in the new model. FedRAMP says agencies should review Ongoing Certification Reports and other FedRAMP Certification Data to understand whether changes to the cloud service offering affect the risk tolerance documented in the agency Authorization to Operate. FedRAMP guidance also says agencies should monitor the provider's change process instead of trying to approve every individual change to a cloud service offering. That creates a buyer-facing expectation: providers should be able to explain how they monitor FedRAMP changes, how they decide what matters, and how they communicate material changes. You do not need to expose every internal note. But you should be able to show: - the official source reviewed; - the decision made; - the affected package, control, KSI, schema, or customer communication surface; - the owner and due date; - the evidence that the action was completed. This is where structured records help. A spreadsheet can work early, but the durable version is a small workflow tied to source links, package artifacts, and customer-visible updates. ## A practical workflow for CSPs Here is the simple version: 1. **Subscribe and mirror.** Track official FedRAMP changelog, notice, rule, and guidance sources. Keep links to the exact source reviewed. 2. **Triage weekly.** Classify each update as reference, package, operating, customer, or no-action. 3. **Map impact.** Connect the update to your certification path, class, package artifact, KSI, Rev 5 control, schema, or customer responsibility. 4. **Escalate early.** Send possible significant changes to the change owner before implementation starts. 5. **Record the decision.** Keep the official source, reviewer, decision, rationale, and completed action together. 6. **Review before publishing package updates.** Before updating certification data or customer-facing documentation, confirm that the source still supports the change. The goal is not to make FedRAMP change tracking heavy. The goal is to make it visible enough that your authorization plan stays current while the program keeps moving. ## FAQ ### Which FedRAMP updates should a CSP review first? Start with official FedRAMP 2026 changelog entries, public notices, and the rules or guidance pages tied to your certification path and class. ### Does every changelog entry require an authorization-plan change? No. The July 1, 2026 changelog entry says it included minor enhancements and fixes with no significant changes to requirements, but teams should still confirm whether wording, schema, or applicability fixes affect internal references. ### Where should significant-change decisions be recorded? Record them with the official source reviewed, the reviewer, the decision, the rationale, and the affected package, KSI, control, schema, or customer communication surface. ### FedRAMP CR26 Transition: What the 2026 Rules Change for Rev 5 and 20x - URL: https://boundera.io/blog/20x/fedramp-cr26-transition-rev5-20x - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-06-29T15:48:14.975Z - Updated: 2026-08-02T19:35:20Z - Reading time: 4 minutes - Main question: What does FedRAMP CR26 change for teams deciding between Rev 5 and 20x? - TL;DR: FedRAMP says the temporary Rev5 Program pipelines for Class B and C close on June 11, 2027, when new Rev5 certification applications stop. - Excerpt: The Consolidated Rules for 2026 take effect on July 4, 2026 and are immediately applicable to offerings seeking to obtain or maintain a FedRAMP Certification. This transition is not a cosmetic rename. The Consolidated Rules for 2026 take effect on July 4, 2026 and are immediately applicable to offerings seeking to obtain or maintain a FedRAMP Certification. The fastest way to read the transition is to separate three decisions: which certification type fits your service, which path is actually available, and which package materials now matter. ## Read the calendar first For FedRAMP 20x, all new applications must follow the applicable Consolidated Rules for 2026 on July 4, 2026. For FedRAMP Rev5, all new applications must follow the applicable Consolidated Rules for 2026 on January 1, 2027. Those two dates should drive backlog planning now. If your team is building against old templates or old review assumptions, you are already planning against the wrong operating model. ## Choose the type that matches the service FedRAMP describes 20x as a modern cloud-native certification type that is new in 2026. FedRAMP describes Rev5 as a modified legacy approach that will be retired in the future. FedRAMP says 20x certifications are processed directly by FedRAMP and do not require an active agency contract or sponsor. FedRAMP says Rev5 typically requires an active agency contract or sponsor and is currently the only option for services that run their own infrastructure or need Class D. FedRAMP anticipates piloting 20x Class D in late 2026 and making it a formal option in early 2027. For many teams, that makes a Class B or C entry path more practical than starting a new legacy track. ## Translate the terminology and package changes In the 2026 guidance, FedRAMP shifts from "authorization" to "FedRAMP Certification" to avoid conflating program certification with an agency authorization to operate. FedRAMP also replaces Impact Levels with Certification Classes A, B, C, and D. FedRAMP says the Certification Package Overview and Security Decision Record replace the historical System Security Plan and appendices. FedRAMP says "Ongoing Certification" replaces "continuous monitoring" as the broader lifecycle term. The 2026 provider guidance says Rev5 package work is moving away from Word and Excel templates toward simplified JSON documents and, in some cases, optional OSCAL. The same guidance says POA&Ms have been eliminated and replaced with a list of Accepted Weaknesses. That combination changes more than vocabulary. It moves the work closer to live system evidence, data structures, and repeatable review workflows. ## Do not assume every path stays open FedRAMP says Program Certification is mostly only available for 20x, while Agency Certification is only available for Rev5. FedRAMP says providers seeking 20x automatically proceed on the Program Certification path. FedRAMP says the temporary Rev5 Program pipelines for Class B and C close on June 11, 2027, when new Rev5 certification applications stop. The Ready Conversion and Lost Sponsor pipelines open on August 10, 2026 and carry a CR26 grace period ending February 19, 2027. If your team is depending on one of those temporary lanes, work backwards from eligibility confirmation, refreshed package data, and the date when the grace period ends. ## Plan the transition like an operating change Existing Rev5 certifications remain active until at least December 31, 2028, unless FedRAMP is otherwise directed. All default CR26 grace periods expire on February 1, 2028, and providers that are not fully following the rules by then lose FedRAMP Certification. For teams already in motion, the practical sequence is straightforward: 1. Decide whether the service should stay on the legacy lane or move toward the modern lane. 2. Replace document-only assumptions with structured package data and current evidence. 3. Rebuild review routines around ongoing reporting, change handling, and accepted weaknesses. 4. Use the deadline that applies to your lane, not the most generous date in the program, as the planning boundary. The main mistake to avoid is treating the change as a terminology cleanup. The guidance makes it a packaging, assurance, and certification-path reset, and teams that plan early will have more room to choose the right lane instead of getting trapped by the last remaining deadlines. ## FAQ ### Does the legacy lane disappear immediately? No. FedRAMP will stop accepting any new Rev5 Certifications on June 11, 2027. Existing Rev5 certifications remain active until at least December 31, 2028. ### Do you need a sponsor for the modern lane? No. FedRAMP says 20x certifications are processed directly by FedRAMP and do not require an active agency contract or sponsor. ### What package change matters most? FedRAMP says the Certification Package Overview and Security Decision Record replace the historical System Security Plan and appendices. ### What FedRAMP 20x Marketplace Movement Means for CSP Readiness - URL: https://boundera.io/blog/20x/fedramp-20x-marketplace-movement-csp-readiness - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-06-25T14:18:00.000Z - Updated: 2026-08-02T19:35:20Z - Reading time: 4 minutes - Main question: What should a provider have ready before the listing starts driving real buyer and assessor scrutiny? - TL;DR: Readiness here is mostly operational: get the listing live, keep the public data surface synchronized, publish dated progress, and keep the package fresh enough to defend on demand. - Excerpt: How CSPs should treat the listing, trust-center surface, and package refresh path as one readiness system instead of three separate tasks. ## Why the listing matters earlier The listing is no longer a final marketing checkpoint. It is the first place an outside reviewer can compare what you say you sell, what you say is in scope, and how credible your assessment path looks. Providers MUST be listed in the FedRAMP Marketplace before applying for FedRAMP Certification. That sequencing change matters more than it first appears. If the listing comes first, the boundary, service naming, and public package surface have to be coherent earlier. Teams that wait until an assessment is on the calendar usually discover mismatches between product marketing, boundary reality, and package structure at the moment scrutiny starts. ## What has to be ready before you ask for certification Providers MUST publicly share up-to-date information about the cloud service offering in both human-readable and JSON formats. In practice, that pushes three readiness questions forward: does the public description match the actual boundary, can a buyer tell which services are in and out, and can the same facts stay synchronized across formats? Providers MUST use automation to ensure information remains consistent between human-readable and machine-readable formats when FedRAMP Certification Data is provided in both formats. That is why a static landing page is not enough. The public page and the structured JSON should come from the same underlying data model, or drift becomes the first signal that the operating system behind the package is weak. A clean service list, current contacts, configuration guidance, and an obvious trust-center entry point all matter because they let a customer decide whether the listing is credible before deeper access is granted. ## What the directory is signaling The current Marketplace data includes impact-level filters for 20x Low and 20x Moderate. The Marketplace data snapshot dated 2026-06-25 shows 66 ready listings, 10 in-process listings, and 528 total listings. Those numbers do not tell you whether your package will pass, but they do show that the directory is behaving more like a live operational surface than a static trophy case. When buyers can sort by status, class, and path, your readiness story becomes comparable before the assessment is complete. Providers MUST demonstrate continuous progress towards a FedRAMP Certification, documented in their Trust Center or website and updated at least quarterly; progress is measured by the provider against documented goals and milestones. The practical read is simple: progress cannot live only in an internal spreadsheet. If the listing is real, the evidence of forward motion has to be visible, current, and specific enough for outsiders to understand what changed since last quarter. ## What an execution-ready team does now Providers MUST supply machine-readable information in JSON documents that are valid against the corresponding JSON schema when a rule contains a FedRAMP JSON schema, UNLESS otherwise specified in the rule. Providers MUST supply a fresh initial FedRAMP Certification Package that shows the current status of the cloud service offering as verified and validated by the provider within the previous 7 days. An execution-ready team turns those requirements into a small operating loop: 1. Lock the public service inventory and naming. 2. Generate the public page and JSON from one source of truth. 3. Publish a quarterly progress log with dated milestones. 4. Keep the package fresh enough that a certification request does not trigger a scramble. 5. Review assessor, trust-center, and service-list data whenever the boundary changes. The teams that move cleanly are not just better at documentation. They make the listing, public data surface, and package-refresh process part of the same release discipline. ## Where most teams lose time Most delays come from translation work. Marketing names do not match service names. The boundary shifts but the public service list does not. Progress updates exist internally but never make it to the trust center. Structured fields are entered by hand, so the JSON and public page drift. If you want marketplace movement to help rather than hurt, treat the public listing as a readiness rehearsal. By the time you are ready to ask for assessment, the outside-facing record should already prove that the package is current, specific, and mechanically maintainable. ### How to Prepare a FedRAMP 20x Authorization Data Sharing Workflow - URL: https://boundera.io/blog/20x/fedramp-20x-authorization-data-sharing-workflow - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-06-22T20:39:59.545Z - Updated: 2026-08-02T19:35:20Z - Reading time: 7 minutes - Main question: How should teams prepare a FedRAMP 20x authorization data sharing workflow? - TL;DR: FedRAMP 20x authorization data sharing should be run as an operating workflow: keep public service information, trust-center access, package overview metadata, restricted certification data, and machine-readable outputs synchronized from controlled source records. - Excerpt: A practical FedRAMP 20x workflow for keeping certification data, trust center content, package overview fields, and JSON outputs in sync. # How to Prepare a FedRAMP 20x Authorization Data Sharing Workflow FedRAMP 20x authorization data sharing is not just a trust-center launch task. It is an operating workflow for keeping certification information current, understandable, and available to the people who need it. FedRAMP 20x Certification Data Sharing rules allow providers to store and share FedRAMP Certification Data through the platform they choose as long as it follows FedRAMP rules for access, accuracy, and transparency. FedRAMP agency guidance says a 20x package is a set of FedRAMP Certification Data that a cloud service provider maintains over time and shares with FedRAMP, agencies, and other necessary parties. That means the practical question is not "where do we upload a PDF?" The practical question is: what system keeps public information, package overview data, trust-center access, policies, service lists, reports, and updates in sync as the cloud service changes? ## Start With The Data Consumers A good workflow starts by naming the audiences. FedRAMP, agency customers, necessary parties, assessors, and public Marketplace readers may need different levels of information from the same certification data system. FedRAMP 20x package guidance says the package may be presented through a provider trust center, a documentation portal, downloadable files, APIs, or a combination of these. The same guidance says the important thing is that required information is accurate, current, understandable, and available in both human-readable and machine-readable forms when required. Use that as the design constraint. A marketing trust page can be the front door, but it cannot be the whole control. The underlying workflow needs owners, update triggers, review steps, machine-readable output, and a way to know when a public or shared record is stale. ## Define The Minimum Public Layer FedRAMP 20x CDS-CSO-PUB says providers must publicly share up-to-date information about the cloud service offering in both human-readable and JSON formats, including available and applicable public information. The listed public information includes the FedRAMP ID, service model, deployment model, business category, UEI number, sales contact information, security contact information, product website link, product logo link, overall service description, service list, secure configuration guidance link, documentation overview, trust center landing page link, next Ongoing Certification Report date, and current FedRAMP Recognized independent assessment service. FedRAMP 20x CDS-CSO-SVC says providers must publicly share a detailed list of specific services and their security categories included in the cloud service offering using clear feature or service names that align with standard public marketing materials. That list must be complete enough for a potential customer to determine which services are and are not included in the FedRAMP Minimum Assessment Scope without requesting access to underlying FedRAMP Certification Data. This is the first useful checkpoint for a team. If sales, product, security, and compliance cannot agree on the public service list, the rest of the authorization data workflow will inherit that ambiguity. ## Treat The Trust Center As A Controlled System FedRAMP provider guidance for Marketplace listing says providers need a website that hosts specific information about the cloud service offering, need to make some information available in a special JSON file for FedRAMP, and need a basic FedRAMP-compatible Trust Center. FedRAMP 20x CDS-CSO-UTC says providers must use a FedRAMP-compatible trust center to store and share FedRAMP Certification Data with all necessary parties. CDS-CSO-CBF says providers must use automation to ensure information remains consistent between human-readable and machine-readable formats when FedRAMP Certification Data is provided in both formats. That is why the trust center should be treated like a product surface with release discipline. Keep a source of truth for each field, decide which fields are public, decide which fields require authenticated access, and automate the JSON output from the same source that feeds human-readable pages. ## Build The Package Overview Workflow The Certification Package Overview rules outline expectations for a simple overview of the cloud service offering that must be included within a FedRAMP Certification Package. FedRAMP 20x CPO-CSO-OVR says providers must supply a Certification Package Overview within their FedRAMP Certification Package, in both human-readable and JSON formats, that includes at least the listed rule-derived information when applicable. CPO-CSO-MTD says providers must include basic metadata in the Certification Package Overview: the name, title, and contact information of the official responsible and accountable for the package, version, date and time of last update, and source of update. For workflow design, that metadata is not filler. It tells reviewers whether the package has an accountable owner, whether the content is versioned, when it last changed, and where the change came from. ## Put Recurring Updates On Rails FedRAMP 20x package guidance says agencies should expect ongoing certification data such as Ongoing Certification Reports, vulnerability information, availability information, change information, incident-related information, and other required updates. For Class C, CPO-CSX-CPM says providers with 20x Class C Certifications must persistently maintain their FedRAMP Certification Package to ensure it is up to date and complete at least once every 2 weeks. The rule notes that providers are expected to maintain their FedRAMP Certification Package using automation as changes occur so it is never out of date. Even when a specific cadence differs by class, the operating pattern is the same: assign update sources, schedule validations, detect stale records, and keep evidence of the refresh. A workflow that depends on someone remembering to edit the trust center after a system change will eventually drift. ## A Practical Workflow Shape A simple 20x authorization data sharing workflow can use five lanes. First, maintain public marketplace and trust-center fields. These include the public service list, service description, contacts, documentation overview, secure configuration guidance link, and trust-center access instructions. Second, maintain package overview data. This includes responsible official metadata, package version, last update timestamp, update source, assessment scope, information resources, information flows, third-party resources, and other applicable package-overview elements. Third, maintain restricted certification data. This includes assessment outputs, ongoing certification reports, vulnerability data, change data, incident-related information, and other materials that may be available only to necessary parties. Fourth, generate machine-readable exports from the same source records used by human-readable pages. The goal is consistency, not duplicate manual entry. Fifth, run a freshness check before each external sharing moment. Before an agency review, assessor handoff, Marketplace update, or quarterly review, confirm that the public layer, package overview, trust-center permissions, and machine-readable output all agree. ## FAQ ### Is a public trust page enough for FedRAMP 20x authorization data sharing? No. FedRAMP 20x rules allow providers to use their chosen platform, but the platform still has to support access, accuracy, transparency, human-readable information, and machine-readable information when required. A public page can be the front door, not the whole workflow. ### What should teams automate first? Start with fields that appear in both human-readable and JSON formats: public service information, package overview metadata, last-update timestamps, source-of-update fields, and trust-center links. Those are the easiest places for manual drift to create review friction. ### SOC 2 to FedRAMP 20x Class A: What Can Carry Forward - URL: https://boundera.io/blog/20x/soc-2-to-fedramp-20x-class-a - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-07-27T19:13:12.568Z - Updated: 2026-08-02T19:30:42Z - Reading time: 1 minutes - Main question: Which SOC 2 Type II materials can support a FedRAMP 20x Class A package? - TL;DR: SOC 2 Type II external assessment materials for this FedRAMP Class A path include a complete report and supporting audit documentation when applicable. - Excerpt: SOC 2 Type II external assessment materials for this FedRAMP Class A path include a complete report and supporting audit documentation when applicable. ## What Changes In The Path SOC 2 Type II external assessment materials for this FedRAMP Class A path include a complete report and supporting audit documentation when applicable. Providers seeking a FedRAMP Class A Certification MUST have completed a certification or equivalent process from FedRAMP Rev5, SOC 2 Type II, or GovRAMP within the past 12 months. ## Evidence Package Differences Providers seeking a FedRAMP Class A Certification MUST supply materials from their alternative security framework assessment to all necessary parties. Teams should treat the prior assessment as input material, not as a complete substitute for current package work. ## Operating Checklist The practical checklist is to inventory prior assessment materials, identify missing evidence, assign evidence ownership, and keep review records current enough for the next review step. ## Takeaway Keep the path practical: reuse what is accepted, map what is missing, and keep the package fresh enough that reviewers can inspect it without rebuilding the story. ### GovRAMP to FedRAMP 20x Class A: What Changes in the Evidence Package - URL: https://boundera.io/blog/20x/govramp-to-fedramp-20x-class-a - Program: FedRAMP 20x - Category: FedRAMP 20x - Published: 2026-07-27T18:02:37.198Z - Updated: 2026-08-02T19:30:42Z - Reading time: 1 minutes - Main question: How should a CSP approach govramp to fedramp 20x for FedRAMP 20x? - TL;DR: Providers seeking a FedRAMP Class A Certification MUST supply materials from their alternative security framework assessment to all necessary parties. - Excerpt: FedRAMP Class A Certification Rules include Approved Alternative Security Frameworks and External Assessment Materials in the Class A certification workflow. ## What Changes In The Path FedRAMP Class A Certification Rules include Approved Alternative Security Frameworks and External Assessment Materials in the Class A certification workflow. Providers seeking a FedRAMP Class A Certification MUST have completed a certification or equivalent process from FedRAMP Rev5, SOC 2 Type II, or GovRAMP within the past 12 months. ## Evidence Package Differences Providers seeking a FedRAMP Class A Certification MUST supply materials from their alternative security framework assessment to all necessary parties. Teams should treat the prior assessment as input material, not as a complete substitute for current package work. ## Operating Checklist The practical checklist is to inventory prior assessment materials, identify missing evidence, assign evidence ownership, and keep review records current enough for the next review step. ## Takeaway Keep the path practical: reuse what is accepted, map what is missing, and keep the package fresh enough that reviewers can inspect it without rebuilding the story. ### The FedRAMP Consolidated Rules Explorer: Every 2026 Rule, Scoped to You - URL: https://boundera.io/blog/20x/consolidated-rules-explorer - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP 20x - Published: 2026-07-09T14:00:00.000Z - Updated: 2026-07-09T16:40:20Z - Reading time: 14 minutes - Main question: How do you know which of the 2026 FedRAMP Consolidated Rules actually apply to you? - TL;DR: The Consolidated Rules Explorer turns the 2026 FedRAMP Consolidated Rules — 249 requirements across 17 rulesets — into a filterable matrix. Set four filters (party, certification type, path, and service class) and it returns exactly what's mandatory, recommended, or optional for you, each with verbatim rule text, deadlines, and NIST SP 800-53 mappings. It reads from the FedRAMP/rules source of truth and exports any scoped view to CSV or JSON. - Excerpt: Meet the Consolidated Rules Explorer: filter all 249 FedRAMP 2026 requirements to what's mandatory, recommended, or optional for you — by party, certification type, path, and Class A–D — with rule text, deadlines, and NIST mappings a click away, exportable to CSV or JSON. The 2026 FedRAMP Consolidated Rules (CR26) retire the vocabulary most teams built their programs around and replace it with 249 requirements spread across 17 rulesets, four service classes, two certification types, and two paths. That's a lot of surface area to read correctly — and almost none of it applies to everyone. The **Consolidated Rules Explorer** collapses all of it into the only question that matters: what is mandatory, recommended, or optional *for you*, with the exact rule text, deadlines, and NIST control mappings one click away. This post is a full tour of what the Explorer does, where its data comes from, and how to use it to scope your obligations in a couple of clicks. You can open it now at [boundera.io/consolidated-rules](https://boundera.io/consolidated-rules). **Key takeaways** - The 2026 Consolidated Rules (CR26) are 249 requirements across 17 rulesets, effective for 20x cloud service providers on July 4, 2026 and intended to run through the end of 2028. - CR26 replaces the old Low / Moderate / High impact levels with four certification classes, A through D. The same requirement can be a MUST at one class and not apply at another. - Set four filters — party, certification type (20x or Rev5), certification path (Program or Agency), and service class (A–D) — and the Explorer returns your in-scope requirements with a live MUST / SHOULD / MAY / MUST NOT count. - For a Class B cloud service provider on the 20x Program path, 157 of the 249 requirements are in scope: 90 MUST, 41 SHOULD, 17 MAY, and 9 MUST NOT / SHOULD NOT. - Every requirement carries its verbatim rule text, its deadline, and its NIST SP 800-53 control mappings — one click away. - Data is read directly from the federal machine-readable source of truth, the FedRAMP/rules repository, so the Explorer reflects the current rules rather than a stale copy. Export any scoped view to CSV or JSON. ## What are the 2026 FedRAMP Consolidated Rules? The Consolidated Rules (often shortened to CR26) are FedRAMP's 2026 rewrite of its requirements into a single, machine-readable rulebook. Instead of prose spread across templates, memos, and baselines, each obligation is a discrete requirement with a stable identifier, a force level (MUST, SHOULD, MAY, or MUST NOT), an applicability by service class, and — where relevant — a deadline and NIST control mapping. Two structural changes matter most. First, the familiar Low, Moderate, and High impact levels give way to four **certification classes**, A through D, that run from a mature commercial service making its first move into the federal market (Class A) to a system handling mission-critical federal information (Class D). We break the classes down in [FedRAMP 20x Class A, B, C, and D Explained](https://boundera.io/blog/20x/fedramp-20x-classes-explained). Second, the rules are published as structured data, so tools can read them directly rather than paraphrasing a PDF. The Explorer is a reader for exactly that structured data — a way to ask: given who I am and what I'm pursuing, what do these 249 requirements actually require of me? ## The problem: the 2026 rules are a matrix, not a checklist Under the old model you could point at Low, Moderate, or High and pull a baseline. CR26 doesn't work that way. A single requirement might be a MUST for a Class D offering, a SHOULD at Class C, and simply not apply at Class A. Layer in whether you're a provider or an assessor, whether you're on the Program or Agency path, and whether you're pursuing 20x or Rev5 (a choice we compare in [FedRAMP 20x vs Rev5](https://boundera.io/blog/20x/fedramp-20x-vs-rev5)), and the question of what you actually have to do stops having a single printed answer. Reading the rules front to back tells you everything every party could ever owe. It doesn't tell you your obligations. That gap — between the full corpus and your scope — is exactly what the Explorer closes. If you're still deciding whether federal authorization applies to you at all, start with [Do You Actually Need FedRAMP?](https://boundera.io/blog/20x/do-you-need-fedramp) and come back once you know you're in. ## Scope the rules to your situation The Explorer is driven by four selectors. Set them to describe yourself, and the requirement set recomputes instantly. | Filter | What it means | Options | | --- | --- | --- | | Party | Who you are in the process | Cloud service provider, federal agency, independent assessor, FedRAMP team member, advisor, or any party | | Certification type | Which track you're on | 20x or Rev5 | | Certification path | How you reach authorization | Program or Agency | | Service class | The assurance tier of your offering | Class A, B, C, or D | Pick a cloud service provider working toward a 20x certification on the Program path with a Class B offering, and the tool tells you that 157 of the 249 requirements are in scope — and breaks that down immediately. Change any selector and the set recomputes: an assessor sees the requirements they must verify; an agency sees its side of the relationship; a Class D provider sees a longer, stricter list than a Class A one. ## Mandatory, recommended, optional, prohibited — at a glance For any scope, the Explorer shows a live tally by force. Here is the breakdown for that same Class B, 20x, Program cloud service provider: | Force | Meaning | Count (CSP · 20x · Program · Class B) | | --- | --- | --- | | Mandatory | MUST / binding | 90 | | Recommended | SHOULD / expected | 41 | | Optional | MAY / allowed | 17 | | Prohibited | MUST NOT / SHOULD NOT | 9 | Two things are easy to miss here. The first is the **prohibited** column: CR26 doesn't only tell you what to do, it tells you what you must *not* do. For example, a provider must not apply for more than one program certification type (`FRC-CSO-POP`), must not have a third party apply on its behalf (`FRC-APP-NTP`), must not include sensitive information in public continuous-monitoring reports (`CCM-OCR-LSI`), and must not disclose vulnerabilities irresponsibly (`VER-RPT-NID`). Those are as binding as any MUST, and easy to overlook if you're only reading for to-dos. The second is that these numbers move the instant you change a filter. Drop from Class B to Class A and much of the matrix falls away — Class A carries the lightest initial set. Move up to Class D and the mandatory count climbs. You are always looking at your obligations, not a generic baseline. ## The same rule, a different force by class The most useful thing the Explorer makes visible is how a single requirement tightens as the class increases. It shows the force for your selected class and dims the values for the others, so the escalation is right there in the row: | Requirement | Class A | Class B | Class C | Class D | | --- | --- | --- | --- | --- | | Using Validated Cryptographic Modules (`CMU-CSO-UVM`) | MAY | MAY | SHOULD | MUST | | Fresh Independent Assessment (`FRC-APP-FIA`) | MAY | MUST | MUST | MUST | | Automated Verification of Key Security Indicators (`FRC-CSX-VVK`) | MAY | SHOULD | MUST | MUST | | Quarterly Review Meeting (`CCM-QTR-MTG`) | MAY | SHOULD | MUST | MUST | Read the top row left to right: using FIPS-validated cryptographic modules is optional for a Class A or B service, expected at Class C, and mandatory at Class D. A dash in the Class A column — which appears on many rows — means the requirement simply doesn't apply at that class, which is why Class A providers see so much of the matrix drop away. If you're planning to certify at a higher class later, this view is the difference between a 'nice to have' today and a hard requirement at your target class, visible before you commit. (The automated-verification rows tie directly to Key Security Indicators; see [What Are FedRAMP 20x KSIs?](https://boundera.io/blog/20x/fedramp-20x-ksi-guide).) ## The 17 rulesets, grouped by lifecycle stage The requirements are organized into rulesets — families like Minimum Assessment Scope or Vulnerability Detection and Response — each with a three-letter code that prefixes its requirement IDs. The Explorer groups the rulesets a provider works through into five lifecycle stages, so you can read them in roughly the order you'll act on them: | Ruleset | Stage | 20x deadline | | --- | --- | --- | | Minimum Assessment Scope (`MAS`) | Scope & prepare | Jul 4, 2026 | | Cryptographic Module Use (`CMU`) | Scope & prepare | Jul 4, 2026 | | Secure Configuration Guide (`SCG`) | Scope & prepare | Mar 1, 2026 | | FedRAMP Certification (`FRC`) | Assess & certify | Jul 4, 2026 | | Independent Verification and Validation (`IVV`) | Assess & certify | Jul 4, 2026 | | Security Decision Record (`SDR`) | Assess & certify | Jul 4, 2026 | | Certification Package Overview (`CPO`) | Assess & certify | Jul 4, 2026 | | Marketplace Listing (`MKT`) | List & share | Jul 4, 2026 | | Certification Data Sharing (`CDS`) | List & share | Jul 4, 2026 | | Collaborative Continuous Monitoring (`CCM`) | Operate & monitor | Jul 4, 2026 | | Vulnerability Detection and Response (`VDR`) | Operate & monitor | Dec 7, 2026 | | Vulnerability Evaluation and Reporting (`VER`) | Operate & monitor | Dec 7, 2026 | | Significant Change Notification (`SCN`) | Operate & monitor | Jul 4, 2026 | | Incident Evaluation and Communication (`IEC`) | Operate & monitor | Jul 4, 2026 | | Addressing FedRAMP Communication (`AFC`) | Operate & monitor | Jan 5, 2026 | A sixth grouping, **Agency use**, covers the agency side of the relationship and appears when you set the party filter to a federal agency. One honest note: the lifecycle stages are Boundera's navigational grouping to make the corpus easier to move through. The ruleset codes, force values, statements, applicability, and dates are read verbatim from the federal source — we don't editorialize those. The vulnerability rulesets (`VDR` and `VER`) are where the old POA&M workflow gives way to persistent detection and response; we cover that shift in [VDR vs POA&M](https://boundera.io/blog/20x/fedramp-20x-vdr-vs-poam), and the monitoring side in [FedRAMP Continuous Monitoring Automation](https://boundera.io/blog/20x/fedramp-continuous-monitoring-automation). ## Every rule, with text, deadlines, and control mappings Scoping is only half the job; you also have to act on each requirement. Every row in the Explorer opens to the exact, verbatim rule statement from the federal source, the deadline that applies to it, and its NIST SP 800-53 control mappings. The deadlines are not uniform — different rulesets come due on different dates: | Obligation area | 20x deadline | | --- | --- | | Addressing FedRAMP Communication (`AFC`) | January 5, 2026 | | Secure Configuration Guide (`SCG`) | March 1, 2026 | | Certification, assessment, listing, monitoring, change, and incident rulesets | July 4, 2026 | | Vulnerability Detection, Evaluation, and Reporting (`VDR`, `VER`) | December 7, 2026 | Because the deadline and the control mapping travel with each requirement, you can go from whether a requirement is in scope to what it says, when it's due, and which NIST controls it satisfies without leaving the row. The NIST mappings are what let a Rev5-style control narrative and a 20x requirement line up against the same evidence — the connective tissue we get into in [OSCAL for FedRAMP](https://boundera.io/blog/20x/oscal-for-fedramp-guide). ## Always current, because it reads the source of truth The Explorer doesn't work from a snapshot someone pasted into a CMS. It reads from [FedRAMP/rules](https://github.com/FedRAMP/rules) — the structured, machine-readable JSON that FedRAMP publishes as the authoritative version of the Consolidated Rules — at version 2026.07.01.01, published July 1, 2026. FedRAMP has said CR26 is intended to be the operating ruleset through the end of 2028, and as it's revised, the Explorer reflects the current text rather than a stale copy. For how the 2026 rollout unfolds over time, see the [FedRAMP 20x Roadmap](https://boundera.io/blog/20x/fedramp-20x-roadmap-2026). Reading from the source has a quiet benefit: the force values, IDs, and dates you see in the Explorer are the same ones a machine-readable evaluation would use, so there's no drift between what you read and what your tooling checks. ## Export to CSV or JSON Any scoped view exports in one click. Take **CSV** into a spreadsheet or a POA&M-style tracker to assign owners and due dates; take **JSON** into your own tooling to drive a checklist, a dashboard, or an evidence pipeline. The export carries your scope, so your engineers get your obligations — not the full 249-row corpus they'd have to filter themselves. Because each row keeps its requirement ID, the export is a natural starting point for a machine-readable readiness tracker rather than a static spreadsheet. ## Who it's for The party filter changes the entire question, so the Explorer serves several audiences from one dataset: - **Cloud service providers** use it to see exactly what a target class demands before committing to it — and to compare the jump from, say, Class B to Class C before signing up for the stricter tier. - **Independent assessors** use it to confirm which requirements are in force for the offering in front of them, so an assessment covers what CR26 actually requires and nothing it doesn't. - **Advisors** use it to scope engagements without re-deriving the matrix by hand for every client. - **Federal agencies** use it to see their side of the relationship — the Agency use obligations that come with consuming an authorized service. - Anyone can switch the party filter to 'any party' to read the whole corpus when they need the complete picture. ## How the Explorer fits your authorization workflow The Explorer answers what applies to me; it's the front door, not the whole house. Once you know your in-scope requirements, the work is turning that list into boundary decisions, evidence, and continuous validation. That's where the rest of a 20x program comes in — Key Security Indicators and their evidence, vulnerability detection and response, and the continuous-monitoring cadence that keeps an authorization live. If you're evaluating how much of that a platform should automate, [FedRAMP Compliance Tools in 2026](https://boundera.io/blog/20x/best-fedramp-compliance-tools-2026) is a good companion read, and [engineering readiness for FedRAMP 20x](https://boundera.io/blog/20x/engineering-readiness-fedramp-20x) covers what your team needs in place first. ## Try it Open the [Consolidated Rules Explorer](https://boundera.io/consolidated-rules), set the four filters to describe your situation, and read your obligations directly. When you're ready to turn that scoped list into an execution plan — control mapping, evidence collection, and continuous monitoring — that's the part Boundera's platform handles. ## Sources - FedRAMP Consolidated Rules for 2026 — fedramp.gov - Using the FedRAMP Consolidated Rules — fedramp.gov - FedRAMP Certification Classes — fedramp.gov - FedRAMP/rules (machine-readable source of truth) — github.com/FedRAMP/rules *Last updated: July 2026. Written by the Boundera team.* ### FedRAMP Continuous Monitoring Automation for 20x ATO - URL: https://boundera.io/blog/20x/fedramp-continuous-monitoring-automation - Program: FedRAMP 20x - Category: Automation - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:43Z - Reading time: 9 minutes - Main question: How do you automate FedRAMP continuous monitoring for a 20x ATO? - TL;DR: FedRAMP continuous monitoring automation collects Key Security Indicator (KSI) evidence directly from your cloud control plane on every infrastructure change. In FedRAMP 20x, Moderate machine validations are expected at least once every 3 days — a cadence that only works when evidence collection is wired into CI/CD. - Excerpt: How to automate FedRAMP 20x continuous monitoring: KSI evidence pipelines, the 3-day cadence, and a 12-line GitHub Action that keeps your ATO green. FedRAMP continuous monitoring automation is the practice of collecting Key Security Indicator (KSI) evidence directly from your cloud control plane on every infrastructure change, rather than gathering it manually each month. In FedRAMP 20x, automation is no longer optional — Moderate machine-based validations are expected at least once every 3 days, which only works when the evidence pipeline is built into CI/CD, not delivered as a quarterly artifact. **Key takeaways** - FedRAMP 20x ConMon is a heartbeat, not a deliverable: your ATO depends on KSI evidence staying current between assessments. - The official validation cadence for Moderate machine-based resources is at least once every 3 days; manual collection cannot keep up. - Three KSI families drive ~70% of ConMon evidence: KSI-MLA (Monitoring, Logging, Auditing), KSI-CNA (Cloud-Native Architecture), and KSI-IAM (Identity and Access Management). - A working automation loop pulls evidence from your cloud APIs, maps it to a specific FRMR KSI ID, and emits OSCAL JSON on every infrastructure change. - The lowest-friction starting point on AWS is a GitHub Action that evaluates Terraform against KSI-MLA-EVC and KSI-CNA-RNT on every pull request. ## What does FedRAMP continuous monitoring mean in 20x? In Rev 5, continuous monitoring (ConMon) was treated as a periodic reporting obligation — monthly vulnerability scans, quarterly POA&M updates, an annual assessment, and a stack of evidence delivered to your AO by email or shared drive. FedRAMP 20x changed the premise. ConMon is no longer a deliverable. It is the *state of your system*, reported as machine-readable [Key Security Indicators](/blog/20x/ksi-vs-ssp) — see the full [FedRAMP 20x KSI guide](/blog/20x/fedramp-20x-ksi-guide) for the complete framework — that the FedRAMP Marketplace can validate on its own cadence. Your authorization remains live only as long as your KSIs remain green. When KSI-IAM-MFA drops below threshold, your ATO does not fail at the next annual review — it fails the moment FedRAMP's continuous validation engine notices. That changes the engineering problem entirely. You are no longer producing a snapshot. You are maintaining a heartbeat. ## How often do FedRAMP 20x validations have to run? Current FedRAMP 20x guidance sets explicit cadence floors for machine-based validations and a slower cadence for non-machine validations. | Resource type | Impact level | Required cadence | | --- | --- | --- | | Machine-based | Low | At least once every 7 days | | Machine-based | Moderate | At least once every 3 days | | Machine-based | High | More frequent than Moderate; specific cadence still pending guidance | | Non-machine | All | At least once every 3 months | > Source: [FedRAMP — Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) The cadence number is not the point. The point is that a CSP needs a repeatable validation program covering the entire service boundary that produces current, structured authorization data without manual intervention. See [Persistent validation in FedRAMP 20x](/blog/20x/fedramp-20x-persistent-validation) for the full operating model. ## Why does manual FedRAMP continuous monitoring break? The standard failure pattern looks the same across nearly every CSP we have seen: 1. **Vulnerability scans run on schedule.** Tenable, Wiz, or Qualys data is fine. CIS benchmark drift gets caught. So far so good. 2. **Configuration evidence is manual.** Someone exports an IAM password policy screenshot, downloads a Config rule snapshot, attaches a CloudTrail Lake export, and pastes everything into a shared Google Drive folder before the monthly review. 3. **GRC tooling consolidates.** A platform like Drata, Vanta, or OneTrust pulls the evidence and maps it to NIST 800-53 controls. Generates a snapshot. Looks correct. 4. **The boundary widens.** Someone enables a new service. A Terraform module changes. A new repo pushes to production. Evidence stops matching reality. 5. **The next ConMon report is wrong.** No one notices for 30 to 90 days. By the time the 3PAO checks, several KSIs have drifted out of compliance. The CSP is flagged and the remediation backlog grows. The root cause is that 60–70% of FedRAMP evidence is structural — IAM policies, network segmentation, encryption-at-rest configuration, logging routing — and structural evidence drifts the moment your IaC changes. Manual collection cadence can never keep up with engineering cadence. The durable answer is to make evidence collection a property of every commit to your infrastructure repository, not a property of the calendar. ## Manual ConMon vs automated ConMon: side by side | Activity | Manual ConMon | Automated ConMon | | --- | --- | --- | | Configuration evidence collection | Screenshots, console exports, monthly | Pulled from cloud APIs on every PR | | KSI mapping | Analyst maps evidence to NIST controls in a spreadsheet | Evidence is tagged with its FRMR mnemonic ID at collection time | | Output format | PDF, CSV, screenshots | OSCAL JSON with integrity hashes | | Cadence | Monthly to quarterly | Per infrastructure change (minutes) | | Annual 3PAO prep | 4–8 weeks of evidence scramble | 3PAO inspects existing GitHub artifacts | | Drift detection | After-the-fact, by exception | Failed CI check before merge | | Analyst hours per month (typical Moderate CSP) | ~25 | <4 | The hours-per-month figure is what most CSPs feel first. The deeper benefit is that the collection cadence finally matches the engineering cadence — every Terraform PR generates fresh evidence before it merges. ## Which KSI families drive ConMon evidence? FedRAMP 20x's Key Security Indicators are grouped into 10 families. For continuous monitoring, three carry roughly 70% of the evidence weight: **KSI-MLA — Monitoring, Logging, Auditing.** Includes `KSI-MLA-EVC` (Evaluating Configurations), `KSI-MLA-CMT` (Centralized Monitoring), and `KSI-MLA-ALA` (Audit Log Aggregation). The "is your cloud configuration what you say it is" family. Most failures live here because IaC drifts faster than humans can keep up. See [the KSI evidence automation guide](/blog/20x/fedramp-20x-ksi-evidence-automation) for a deeper walkthrough. **KSI-CNA — Cloud-Native Architecture.** Includes `KSI-CNA-RNT` (Restricting Network Traffic), `KSI-CNA-LPV` (Least Privileged Network Access), and `KSI-CNA-IMM` (Immutable Infrastructure). The "is your boundary what you say it is" family. Subnet changes, security group edits, and new ingress paths break these without anyone noticing. **KSI-IAM — Identity and Access Management.** Includes `KSI-IAM-MFA` (MFA Enforcement), `KSI-IAM-LPR` (Least Privilege), and `KSI-IAM-SVC` (Service Account Hygiene). The "is your access control what you say it is" family. Most CSPs have *some* MFA. Few can produce continuous evidence that 100% of privileged users have MFA enforced at the IdP and never bypass via console-recovery flows. Automating evidence for these three families covers the majority of ConMon's continuous-evidence surface. The remaining KSI families (CMT, AFR, PIY, and so on) are less volatile and can be evaluated on a slower cadence. ## How do you build an automated FedRAMP ConMon loop? A practical automation loop has six parts and runs entirely inside infrastructure your engineering team already trusts: ### 1. Scope Start with the resources and processes inside the authorization boundary. If the boundary is wrong, validation coverage will be wrong. ### 2. Collect Pull evidence from authoritative systems on every infrastructure change. Prefer cloud APIs, identity provider APIs, and CI/CD logs over manual exports or screenshots. ### 3. Map Tag every artifact with its FRMR mnemonic ID (`KSI-MLA-EVC`, `KSI-CNA-RNT`, `KSI-IAM-MFA`) — not a legacy numeric ID, not an ad-hoc control reference. Mismatched mapping is the most common reason 3PAOs reject evidence packs. ### 4. Evaluate Run deterministic checks against the canonical FRMR documentation. Pass / fail / error results need to be reproducible across runs. ### 5. Route A failed validation should create work, not a Slack message. Route findings to the right owner with the failed assertion, affected resource, and a recommended remediation path. ### 6. Report Emit results as [OSCAL](/blog/20x/oscal-for-fedramp-guide) JSON with SHA-256 integrity hashes. Pipe them into your GRC tool, attach them to your monthly submission, or hand them straight to your 3PAO. ## How Boundera automates FedRAMP continuous monitoring (a 12-line walkthrough) The `Boundera/fedramp-20x-ksi-action` GitHub Action — open source, MIT licensed — evaluates Terraform IaC against the canonical FRMR documentation on every commit. It checks `KSI-MLA-EVC` and `KSI-CNA-RNT` natively today, with more KSI checks added on each release. The architectural choice that matters most: **no vendor server sits in the data path.** The action runs inside your repository's GitHub Actions runner using the workflow's built-in `GITHUB_TOKEN`. Your IaC, your evidence, and the Check Run results never leave GitHub. That removes the boundary objection 3PAOs would otherwise need to raise when a vendor backend sits between the CSP and the evidence. Full onboarding for a customer using Terraform on AWS is one workflow file: ```yaml # .github/workflows/fedramp-ksi.yml name: FedRAMP 20x KSI Evidence on: pull_request: paths: ['terraform/**', '**/*.tf'] push: branches: [main] permissions: contents: read checks: write jobs: ksi: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: Boundera/fedramp-20x-ksi-action@v1 ``` On every pull request, the action posts a Check Run to the commit with KSI status. On every merge to `main`, it produces a signed evidence pack as a standard GitHub Actions artifact. Pipe it to S3 for retention, attach it to your monthly ConMon submission, or hand it directly to your 3PAO. This is the open-source path. For the full ConMon loop with all 10 KSI families, AI-generated remediation recommendations, OSCAL package assembly, and direct 3PAO integration, [request a demo](/request-demo). ## Common FedRAMP ConMon failure modes — and how automation fixes each one **"We had MFA when we got our ATO. We added a new admin role last quarter and forgot to enforce MFA on it."** With automated ConMon, `KSI-IAM-MFA` runs on every IaC change. The new role's lack of MFA fails the Check Run before the PR merges. **"Our network segmentation diagram in the SSP does not match prod anymore. Someone opened a new ingress for the data team six months ago."** `KSI-CNA-RNT` evaluates ingress and egress paths against your declared boundary on every Terraform plan. Boundary drift produces a failed Check Run with the exact diff. **"Our CloudTrail is logging, but it is writing to a bucket that does not have object-lock or cross-account replication."** `KSI-MLA-ALA` evaluates audit log aggregation properties (immutability, retention, cross-account redundancy) and fails until they match the KSI specification. **"Our 3PAO came back with 14 findings on KSI-MLA-EVC because none of our Config rules were enabled in the new ap-south-1 region."** The action evaluates every Terraform-defined region against `KSI-MLA-EVC`. Adding a region without the required Config rule set fails before merge. ## Frequently asked questions ### Is FedRAMP continuous monitoring the same as vulnerability scanning? No. Vulnerability scanning (Wiz, Tenable, Qualys) finds CVEs and misconfigurations. FedRAMP continuous monitoring is broader — it covers structural evidence mapped to specific KSIs. A scanner tells you a high-severity CVE exists. ConMon tells you whether your `KSI-MLA-ALA` evidence package is still current. Both are required. ### Does automation replace a SIEM or GRC platform? No. Automation generates the FRMR-tagged evidence; your SIEM keeps doing detection, and your GRC tool keeps aggregating. Where automation replaces work is in the manual evidence-collection and KSI-mapping steps that sit between your control plane and your GRC tool — typically 70–80% of GRC analyst time during ConMon. ### Does this work on Azure and GCP, or only AWS? The `Boundera/fedramp-20x-ksi-action` open-source release ships with the deepest KSI mappings on AWS today (full KSI-IAM and KSI-MLA coverage in the [fedramp-20x-toolkit](/blog/20x/fedramp-20x-toolkit)). Azure and GCP mappings are in active development. CSPs on those clouds can use the Boundera platform directly. ### What about FedRAMP Rev 5 — does this work pre-20x? Yes. The KSI evidence is 20x-native, but the underlying NIST 800-53 control crosswalks ship inside the toolkit. Rev 5 customers can automate evidence collection today and switch the output mode to KSI-tagged when they migrate to 20x. See [Rev 5 ConMon checklist](/blog/rev5/fedramp-conmon-checklist) for the Rev 5 baseline. ### Is the evidence considered "machine-readable" by FedRAMP? Yes. Output is OSCAL JSON with FRMR KSI tags. OSCAL is the FedRAMP-published machine-readable format. The major 3PAOs (Coalfire, Schellman, A-LIGN, Kratos) consume OSCAL natively. ### How long does it take to wire this into a CI/CD pipeline? The GitHub Action is 12 lines of YAML and a single push to `main`. Real-world setup including scoping which KSIs to evaluate and which Terraform paths to scan: 30 to 60 minutes for a small team. ### Will assessors accept evidence generated this way? Yes, when it is FRMR-tagged OSCAL with SHA-256 integrity. The assessor's job is to validate that the evidence is current, authentic, mapped to a specific KSI, and produced by a repeatable process. Automated evidence packs meet all four conditions more reliably than screenshots. ## Sources - [FedRAMP — Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [FedRAMP 20x Overview](https://www.fedramp.gov/20x/) - [FRMR Machine-Readable Documentation, v0.9.43-beta](https://github.com/GSA/fedramp-automation) - [NIST SP 800-53 Rev 5 Control Catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP 20x Toolkit: Open-Source KSI Mappings & Example Packages - URL: https://boundera.io/blog/20x/fedramp-20x-toolkit - Program: FedRAMP 20x - Category: Automation - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:42Z - Reading time: 7 minutes - Main question: What open-source tools help map evidence to FedRAMP 20x KSIs? - TL;DR: Boundera's open-source FedRAMP 20x Toolkit gives CSPs practitioner-grade AWS-to-KSI evidence mappings for the IAM and MLA families and machine-readable example packages (a sample KSI package and an SSP fragment) to use as references. It is MIT-licensed and alpha (v0.1.x), targets FRMR v0.9.43-beta, and covers two of the eleven KSI families publicly. A KSI-specific package validator is on the roadmap. - Excerpt: An open-source toolkit of AWS-to-KSI evidence mappings and machine-readable example packages to help you prepare a FedRAMP 20x submission. # FedRAMP 20x Toolkit: Open-Source KSI Mappings & Example Packages Preparing a FedRAMP 20x submission means turning abstract Key Security Indicators into concrete evidence — and figuring out, indicator by indicator, exactly which cloud signals prove each one. Boundera's open-source [FedRAMP 20x Toolkit](https://github.com/Boundera/fedramp-20x-toolkit) gives you a practitioner-grade head start: real AWS-to-KSI evidence mappings and machine-readable example packages you can use as references. It's MIT-licensed and free. **Key takeaways** - It publishes detailed **AWS evidence mappings** for two KSI families — Identity & Access Management (KSI-IAM) and Monitoring, Logging & Auditing (KSI-MLA). - It ships **machine-readable JSON example packages** — a sample KSI package and an SSP fragment — so you know what good looks like. - It's **alpha (v0.1.x)**, targets FRMR v0.9.43-beta, and covers 2 of the 11 KSI families publicly — a free reference, with full coverage in Boundera's product. ## Why a toolkit? The hardest part of a 20x submission isn't understanding what a KSI *means* — it's the gap between the requirement and the evidence. "Enforce phishing-resistant MFA" is clear enough; what's not obvious is which AWS Config rule, which Security Hub control, or which CloudWatch metric an assessor will actually accept as proof, and what a well-formed evidence reference looks like in OSCAL. Teams burn weeks rediscovering those mappings from scratch. This toolkit writes them down. For each indicator it maps, it states the requirement in plain English, names two or three concrete AWS evidence sources that satisfy it, shows the shape of valid evidence, and flags the gaps engineers commonly hit during readiness. Shared, public mappings reduce ambiguity for everyone preparing a 20x submission — which is why it's open source. ## What's inside | Component | What it gives you | | --- | --- | | `ksi-mappings/aws/iam` | All 7 KSI-IAM indicators mapped to AWS evidence sources (MFA, passwordless, non-user auth, just-in-time, least privilege, suspicious-activity response, automated account management) | | `ksi-mappings/aws/mla` | All 5 KSI-MLA indicators (SIEM operation, log review, configuration evaluation, event-type logging, log-access authorization) | | `examples/` | A full machine-readable JSON KSI package and an SSP snippet referencing KSI evidence | | `docs/` | Plain-language explainers, including how the repo relates to the commercial product | Each mapping file carries provenance — the FRMR version it targets and a last-validated date — so you can trust which release it reflects. The indicator IDs follow the current mnemonic naming (for example `KSI-IAM-MFA`, `KSI-MLA-OSM`), with the older numeric IDs preserved as a "formerly known as" field for packages authored against earlier releases. ## Validating your KSI package The example packages exist so you can see exactly what a well-formed KSI package looks like before you build your own. A KSI-specific validator — one that adds structure and indicator-level checks — is on the roadmap rather than shipped today. If your package is in OSCAL, you can also run it through the official [NIST OSCAL CLI](https://github.com/usnistgov/oscal-cli) for schema validation. For the role OSCAL plays in FedRAMP — and how to get your documentation into it — see our [guide to converting an SSP to OSCAL](/blog/20x/ssp-to-oscal-guide) and the [OSCAL for FedRAMP explainer](/blog/20x/oscal-for-fedramp-guide). ## What it covers — and what it doesn't The toolkit maps two of the eleven KSI families on AWS. The other nine families — and Azure and GCP coverage — are not in the public repo; that's where Boundera's commercial product comes in, with automated evidence collection across all indicators and clouds, continuous posture, and audit-ready package generation. The toolkit is a genuine, useful reference on its own; it's just honest about its scope rather than pretending to be a complete solution. It pairs naturally with the [FedRAMP 20x KSI GitHub Action](/blog/20x/fedramp-20x-ksi-github-action), which validates Terraform IaC against the configuration KSIs in CI, and with our deeper write-up on [implementing KSI checks as first-class objects](/blog/20x/fedramp-20x-ksi-checks-implementation). ## Frequently asked questions ### What is the FedRAMP 20x Toolkit? An open-source, MIT-licensed repository of AWS-to-KSI evidence mappings and machine-readable example packages, intended to help Cloud Service Providers prepare FedRAMP 20x submissions. It's maintained by Boundera. ### How many KSIs does it map? It publicly maps two of the eleven KSI families on AWS — KSI-IAM (7 indicators) and KSI-MLA (5 indicators). The full FRMR set is 11 families and 60 indicators; the remaining families and other clouds are covered in Boundera's commercial product. ### Is there a tool to validate my KSI package? Not yet in this toolkit — a KSI-specific validator is on the roadmap. Today, use the toolkit's example packages as a reference for correct structure; if your package is in OSCAL, the official [NIST OSCAL CLI](https://github.com/usnistgov/oscal-cli) can confirm it is schema-valid. ### Can I submit the example packages? No. The `examples/` files are illustrative references to show the correct structure; they aren't based on any real system. Use them as a template, not a submission. ### What FRMR version does it target? The mappings target FRMR v0.9.43-beta (last updated April 2026). Each mapping carries a version and last-validated field, and the project aims to update mappings shortly after FedRAMP publishes changes upstream. ### Is it stable? It's **alpha (v0.1.x)** — the mappings and validator work, but interfaces may change before v1.0, with breaking changes flagged by a SemVer major bump. ## Sources - [Boundera/fedramp-20x-toolkit (GitHub)](https://github.com/Boundera/fedramp-20x-toolkit) - [FedRAMP 20x Key Security Indicators (fedramp.gov)](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [NIST OSCAL](https://pages.nist.gov/OSCAL/) - [GSA fedramp-automation](https://github.com/GSA/fedramp-automation) --- _Last updated: June 2026. Written by the Boundera team._ ### Run FedRAMP 20x KSI Checks in CI: The Boundera GitHub Action - URL: https://boundera.io/blog/20x/fedramp-20x-ksi-github-action - Program: FedRAMP 20x - Category: Automation - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:41Z - Reading time: 7 minutes - Main question: How do you check FedRAMP 20x KSIs in your CI pipeline? - TL;DR: Boundera's open-source FedRAMP 20x KSI GitHub Action evaluates your Terraform IaC against KSI-MLA-EVC and KSI-CNA-RNT on every commit, posts a pass/fail Check Run, and uploads a hash-verified evidence pack a 3PAO can review. It runs entirely in your own GitHub Actions runner with no vendor server, so evidence never leaves GitHub infrastructure. It is MIT-licensed, live on the GitHub Marketplace, and currently alpha (v0.1.0) covering two infrastructure-configuration KSIs. - Excerpt: An open-source GitHub Action that evaluates your Terraform against FedRAMP 20x KSIs on every commit - no vendor server, evidence stays in your runner. # Run FedRAMP 20x KSI Checks in CI: The Boundera GitHub Action You can now validate your Terraform against FedRAMP 20x Key Security Indicators on every commit — without standing up any infrastructure or sending your evidence to a vendor. Boundera's open-source [FedRAMP 20x KSI Action](https://github.com/Boundera/fedramp-20x-ksi-action) runs entirely inside your own GitHub Actions runner, posts a pass/fail Check Run on your commits, and produces a hash-verified evidence pack a 3PAO can review. It's MIT-licensed and live on the [GitHub Marketplace](https://github.com/marketplace/actions/fedramp-20x-ksi-action). **Key takeaways** - The action evaluates your **Terraform IaC** against two KSIs today: **KSI-MLA-EVC** (Evaluating Configurations) and **KSI-CNA-RNT** (Restricting Network Traffic). - **No vendor server.** Everything runs in your runner; your evidence never leaves GitHub-managed infrastructure — which avoids a real FedRAMP boundary problem. - It posts a **Check Run** per commit and uploads an **evidence pack** with SHA-256 integrity hashes, retained as a workflow artifact. - It's honestly **alpha (v0.1.0)** and covers 2 of the program's KSIs — a focused, free starting point, not full coverage. ## What problem does it solve? FedRAMP 20x expects security evidence to be machine-readable, regenerable on demand, and produced by a persistent, automated cycle rather than a once-a-year screenshot exercise. For the indicators that govern infrastructure configuration, the most natural place to prove that is the same CI pipeline that already builds and deploys your system. If your infrastructure is defined in Terraform, your IaC is the source of truth for whether logging is evaluated and whether network traffic is restricted — so checking it on every change is exactly the "persistent validation" the program is asking for. The catch with most compliance tooling is that it phones home: evidence flows through a vendor-operated backend to render a dashboard or post a status. For a cloud service provider whose runtime is in scope for FedRAMP, routing in-scope evidence through non-authorized infrastructure is a boundary question you'd rather not answer. This action is designed so that question never comes up. ## How it works (no server in the loop) The action is a self-contained step that runs on your `ubuntu-latest` runner. On each run it detects Terraform, initializes and validates it, builds an inventory from the HCL, evaluates the in-scope KSIs against that inventory, assembles an evidence pack with integrity hashes, and posts the result as a Check Run using the workflow's built-in `GITHUB_TOKEN`. Its only outbound calls are to GitHub's own API and the Terraform registry — nothing transits a Boundera server. | Stage | What happens | Where it runs | | --- | --- | --- | | Detect & validate | Find Terraform, `terraform init`/`validate` | Your runner | | Inventory | Parse HCL into a resource + network inventory | Your runner | | Evaluate | Score each in-scope KSI against the inventory | Your runner | | Evidence pack | Manifest + inventories + SHA-256 hashes | Workflow artifact | | Report | Pass/fail Check Run on the commit | GitHub API | Because the evidence pack is a structured manifest with hashes — not a screenshot — it's the kind of artifact you can hand directly to a 3PAO and regenerate on demand, which is what [the KSI validation rules](/blog/20x/fedramp-20x-ksi-validation) require. ## Quick start Add a workflow like this to any repo that contains Terraform: ```yaml name: FedRAMP KSI on: schedule: - cron: '0 0 * * *' # daily — supports the persistent-validation cadence workflow_dispatch: permissions: contents: read actions: read checks: write # required so the action can post a Check Run jobs: evaluate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: Boundera/fedramp-20x-ksi-action@v1 ``` That's the whole integration — no app to install, no webhook, no secret to configure. The scheduled run matters: persistent validation is about a recurring cadence, so the daily trigger is what makes the evidence "current" rather than a one-off. ## What it covers today (and what it doesn't) This is an early, deliberately narrow release. It maps the two infrastructure-configuration KSIs that Terraform can authoritatively answer: | KSI | Name | Theme | | --- | --- | --- | | `KSI-MLA-EVC` | Evaluating Configurations | Monitoring, Logging & Auditing | | `KSI-CNA-RNT` | Restricting Network Traffic | Cloud Native Architecture | The other 50-plus indicators across the remaining KSI families are out of scope for this action — many of them simply can't be proven from Terraform alone (they need runtime config, identity data, logs, or human-process evidence). Some of those are mapped in the companion open-source [FedRAMP 20x toolkit](/blog/20x/fedramp-20x-toolkit), and full multi-cloud, automated coverage is what Boundera's commercial product is for. We'd rather ship a small thing that's honest about its scope than a big thing that overpromises. ## Where it fits in a 20x program Think of this action as one instrument in a larger evidence pipeline, not the whole thing. It's a clean, free way to start treating KSIs as continuously-validated checks in the place engineers already live — the pull request. For the architecture behind that idea, see our guide on [implementing KSI checks as first-class objects](/blog/20x/fedramp-20x-ksi-checks-implementation), and for the broader picture of [automating KSI evidence collection](/blog/20x/fedramp-20x-ksi-evidence-automation) across your whole environment. ## Frequently asked questions ### Is the FedRAMP 20x KSI Action free? Yes. It's open source under the MIT license and free to use from the GitHub Marketplace. It runs on your own GitHub Actions minutes. ### Does my evidence get sent to Boundera? No. The action runs entirely inside your GitHub Actions runner, and its only outbound calls are to GitHub's API (to post the Check Run) and the Terraform registry (during `init`). No evidence transits a Boundera-operated server. ### Which KSIs does it check? Two, as of v0.1.0: `KSI-MLA-EVC` (Evaluating Configurations) and `KSI-CNA-RNT` (Restricting Network Traffic), both evaluated against your Terraform IaC. Legacy numeric IDs are accepted and auto-mapped. ### Can I hand the output to a 3PAO? Yes. Each run uploads an evidence pack containing a machine-readable manifest, the Terraform and network inventories, and SHA-256 hashes over every file for integrity. A 3PAO reviews the artifact directly — there's no vendor portal in between. ### Is it production-ready? It's labeled **alpha (v0.1.x)**. The evaluation criteria, evidence format, and Check Run output are stable enough for daily use, but interfaces may change before v1.0, and breaking changes get a SemVer major bump. Treat it as a strong starting point, not your entire compliance program. ### What FedRAMP spec does it evaluate against? It bundles the FedRAMP machine-readable (FRMR) documentation it scores against, pinned to a specific version, so evaluations are hermetic and reproducible. Mappings are updated shortly after FedRAMP publishes changes upstream. ## Sources - [Boundera/fedramp-20x-ksi-action (GitHub)](https://github.com/Boundera/fedramp-20x-ksi-action) - [FedRAMP 20x KSI Action on the GitHub Marketplace](https://github.com/marketplace/actions/fedramp-20x-ksi-action) - [FedRAMP 20x Key Security Indicators (fedramp.gov)](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [FedRAMP 20x Persistent Validation and Assessment (fedramp.gov)](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) --- _Last updated: June 2026. Written by the Boundera team._ ### How to Implement FedRAMP 20x KSI Checks (Checks as Objects) - URL: https://boundera.io/blog/20x/fedramp-20x-ksi-checks-implementation - Program: FedRAMP 20x - Category: Automation - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:40Z - Reading time: 14 minutes - Main question: How do you implement FedRAMP 20x KSI checks as first-class objects? - TL;DR: Model each FedRAMP 20x KSI check as a first-class object with a stable identity, declared inputs, a validation method, a structured machine-readable result, a cadence, an owner, and a failure path. Each check reads current state from an authoritative source and asserts one condition; results roll up deterministically into a KSI assertion. This makes evidence regenerable on demand, runs on the 7-day (Low) / 3-day (Moderate) cadence, and treats any failed or broken validation as a vulnerability. - Excerpt: Implement FedRAMP 20x KSI checks as first-class objects: a stable identity, inputs, a validation method, a result, a cadence, an owner, and a failure path. Six check types, with code. # How to Implement FedRAMP 20x KSI Checks (Checks as First-Class Objects) To implement FedRAMP 20x Key Security Indicator (KSI) checks well, model each check as a **first-class object** with a stable identity, declared inputs, a validation method, a structured result, a cadence, an owner, and a defined failure path — instead of burying logic in scripts that emit screenshots. Every check fetches current state from an authoritative source, asserts a single condition against it, and returns a machine-readable result that rolls up into a KSI assertion. This is what lets a 20x evidence pipeline regenerate proof on demand, run on FedRAMP's validation cadence (at least every 7 days at Low, every 3 days at Moderate for machine-based resources), and treat any broken validation as a vulnerability. **Key takeaways** - A KSI check is **one assertion**: smallest unit you would enable, disable, schedule, or attribute to an owner. Stable identity is the keystone — everything else (results, findings, cadence, audit trail) keys off it. - The check object has seven fields: **identity, inputs, validation method, result, cadence, owner, failure path**. Define these as data, keep the predicate as a small pure function. - There are six recurring **check types**: cloud configuration, log/status, state/inventory, serverless (Lambda) custom logic, Terraform/IaC static analysis, and application source-code analysis. Each emits the same result shape. - Results roll up deterministically: per-resource pass/fail → per-assertion verdict → KSI assertion → pass/fail summary. Keep the math explicit and reproducible. - A **failed or broken validation is a vulnerability** under FedRAMP 20x and must route to Vulnerability Detection and Response (VDR), not a silent retry. - Screenshots are not an acceptable system of record. The check's output must be machine- and human-readable and regenerable on demand. This post is the implementation companion to our guide on how to [automate KSI evidence collection](/blog/20x/fedramp-20x-ksi-evidence-automation). That post covers the pipeline; this one covers the object at the center of it. ## What does "checks as first-class objects" mean? It means a check is a real, addressable thing in your system — a record with an identity and configuration — not an anonymous block of code that happens to run during a scan. The contrast is concrete. In the naive design, "is CloudTrail logging enabled" lives inside a 400-line scan script, has no name you can reference, runs for every customer whether or not it applies, and produces a finding you can only suppress one resource at a time. In the first-class design, that same logic is one row in a check catalog with the identifier `aws_cloudtrail_logs_enabled`, a known input signal, a one-line predicate, a severity, an owner, and a cadence. You can list it, enable or disable it per environment with a recorded reason, point a finding back to it, and reproduce its result on demand. The single design decision that unlocks all of this is **granularity: one check per assertion**. The smallest unit a team would reasonably want to toggle, schedule, or attribute separately is one assertion ("AWS Config recorder is recording"), not a whole bundle ("the entire Change Management evaluation"). If your unit of identity is too coarse, "we don't run Azure" also disables your AWS and GCP predicates, and a failing finding can't point at the specific thing that broke. Pin a stable `assertion_id` to every predicate first; the rest of the architecture hangs off it. | Without first-class checks | With first-class checks | | --- | --- | | Logic hidden in scan scripts | Each check is a named, addressable object | | Every customer runs every check | Per-environment enable/disable with a reason | | Findings can't reference their source | Finding carries the producing `assertion_id` | | No audit trail for scoping decisions | Who disabled what, when, and why is recorded | | Hard to add custom checks | New check = new catalog entry, same contract | ## What fields does a KSI check object have? A KSI check object carries everything needed to run it, schedule it, interpret its output, and act on a failure. We model it as seven fields. Identity and the validation method are immutable parts of the check definition; cadence and owner are policy you attach; the result is what the check emits each run. | Field | What it is | Example | | --- | --- | --- | | **Identity** | Stable, unique `assertion_id`; the KSI it serves; provider; severity | `aws_cloudtrail_logs_enabled` · `KSI-MLA-LOG` · `aws` · `high` | | **Inputs** | The signal/resource type the check reads, from an authoritative source | `aws:cloudtrail:trails` | | **Validation method** | The predicate: a pure function `(resource) -> bool` plus pass/fail messages | "trail status `IsLogging == true`" | | **Result** | Structured pass/fail per resource, plus human-readable reason and snapshot | `{status, resource_id, reason, snapshot, observed_at}` | | **Cadence** | How often it must run, derived from impact level and machine vs. non-machine | every 3 days (Moderate, machine-based) | | **Owner** | Who remediates a failure and where the work item lands | platform-security team · Jira project | | **Failure path** | What happens on fail or on a broken run: open a VDR-tracked vulnerability | route to VDR with assertion id + resource | A clean way to declare the identity-and-inputs-and-method triple is a small dataclass that binds a signal to a predicate. The predicate stays pure — it takes one resource dict and returns a boolean — so it is trivially testable and free of I/O: ```python from dataclasses import dataclass from typing import Callable @dataclass(frozen=True) class CheckDef: assertion_id: str # stable identity, e.g. "aws_cloudtrail_logs_enabled" ksi_id: str # the KSI it serves, e.g. "KSI-MLA-LOG" provider: str # "aws" | "azure" | "gcp" | "scm" | "code" | ... signal: str # authoritative input, e.g. "aws:cloudtrail:trails" severity: str # "low" | "moderate" | "high" | "critical" condition: Callable[[dict], bool] # the predicate — pure, no I/O passing_msg: Callable[[dict], str] failing_msg: Callable[[dict], str] snapshot_fields: list[str] # keys to capture into evidence ``` The catalog of `CheckDef` rows is the registry. Cadence, owner, and per-environment enable/disable are *configuration layered on top* — they should not live inside the predicate. Keeping the validation logic separate from registration is what lets you disable a check for one customer (with a recorded reason that feeds your audit trail) without touching code, and lets a finding cascade-dismiss when its check is turned off. Anything else — custom customer-defined checks, bulk "disable all Azure compute" actions, agent-suggested scoping — is a natural extension once the object exists. ## How do check types map to KSI themes? FedRAMP 20x organizes security outcomes into [11 KSI themes](https://www.fedramp.gov/docs/20x/key-security-indicators/), and most validations reduce to one of six check types. The type tells you *where the input comes from* and *how the predicate runs*; the result shape is identical across all six. (For why a KSI is a different artifact than a control narrative, see [KSIs vs the SSP](/blog/20x/ksi-vs-ssp).) | Check type | Reads from | Primary KSI themes | | --- | --- | --- | | Cloud configuration | Cloud config API | Service Configuration, Cloud Native Architecture | | Log / status | Monitoring / logging source | Monitoring, Logging & Auditing | | State / inventory | Running system or tracked record | Policy & Inventory, Change Management | | Serverless (Lambda) custom logic | A function that returns structured pass/fail | Any theme needing custom logic | | Terraform / IaC static analysis | Infrastructure-as-code in your repos | Change Management, Cloud Native Architecture | | Application source-code analysis | App source/config in your repos | Service Configuration, IAM | Each subsection below shows the input, the validation logic, and the structured result — the three things every first-class check must define. ### 1. Cloud configuration check A configuration check fetches current cloud config and asserts a single property: encryption is on, logging is enabled, a public endpoint is closed. The pattern is **fetch then assert**. Collection (the cloud API call) happens upstream and lands a normalized resource record; the check is a pure predicate over that record. Input — a normalized resource dict per S3 bucket: ```json { "resource_id": "prod-evidence-store", "encryption_type": "aws:kms", "kms_key_arn": "arn:aws:kms:...:key/abc", "observed_at": "2026-06-04T11:02:09Z" } ``` Validation logic — encryption at rest must use a KMS key: ```python def s3_encrypted_with_kms(r: dict) -> bool: return r.get("encryption_type") == "aws:kms" and bool(r.get("kms_key_arn")) check = CheckDef( assertion_id="aws_s3_encryption_at_rest", ksi_id="KSI-SVC-ENC", provider="aws", signal="aws:s3:buckets", severity="high", condition=s3_encrypted_with_kms, passing_msg=lambda r: f"Bucket {r['resource_id']} encrypted with KMS", failing_msg=lambda r: f"Bucket {r['resource_id']} not KMS-encrypted", snapshot_fields=["encryption_type", "kms_key_arn"], ) ``` Structured result: ```json { "assertion_id": "aws_s3_encryption_at_rest", "status": "FAIL", "resource_id": "prod-evidence-store", "reason": "Bucket prod-evidence-store not KMS-encrypted", "snapshot": { "encryption_type": "AES256", "kms_key_arn": null }, "observed_at": "2026-06-04T11:02:09Z", "source": "aws:s3:buckets" } ``` ### 2. Log / status check A log/status check pulls a status or recent log signal from a monitoring source and evaluates it — the core of the Monitoring, Logging & Auditing theme. The predicate is the same shape; the input is a status record rather than a static config. A common pitfall is asserting "a trail exists" instead of "a trail is actively logging." Existence is not evidence; current status is. Input — a CloudTrail trail status record: ```json { "resource_id": "org-trail", "is_logging": true, "delivers_to_cloudwatch": true, "latest_delivery_error": null, "observed_at": "2026-06-04T11:02:11Z" } ``` Validation logic — the trail must be logging *and* delivering to CloudWatch for real-time monitoring: ```python def cloudtrail_actively_logging(r: dict) -> bool: return (r.get("is_logging") is True and r.get("delivers_to_cloudwatch") is True and not r.get("latest_delivery_error")) ``` The result is identical in shape to the configuration check (`status`, `resource_id`, `reason`, `snapshot`, `observed_at`, `source`). That uniformity is the point: a downstream aggregator never needs to know which type produced a result. ### 3. State / inventory check A state/inventory check verifies something about the running system or a tracked record — does the AWS Config recorder actually record, is every production resource in the inventory, is the change log current. This is the "check something in an app or data store" pattern, and it maps to Policy & Inventory and Change Management. The input is a system record; the predicate asserts the desired state. Input and logic — the configuration recorder must be recording: ```python def config_recorder_active(r: dict) -> bool: return r.get("recording") is True check = CheckDef( assertion_id="aws_config_recorder_recording", ksi_id="KSI-CMT-BAS", provider="aws", signal="aws:config:recorders", severity="high", condition=config_recorder_active, passing_msg=lambda r: f"Config recorder {r['resource_id']} is recording", failing_msg=lambda r: f"Config recorder {r['resource_id']} stopped — drift untracked", snapshot_fields=["recording", "name"], ) ``` For an *inventory completeness* check, the predicate runs over the join of "resources the connector sees" and "resources the inventory claims," and fails any resource present in one set but not the other. The result still carries a `resource_id` and a `reason`, so a missing resource becomes a first-class finding rather than a silent gap — which matters because assessors verify that every information resource you list is actually being validated. ### 4. Complex check via a serverless function (AWS Lambda) When a check needs custom logic that does not reduce to a one-line predicate over a single record — correlating across services, walking an IAM policy graph, computing a derived condition — run it as a serverless function and have it return the **same structured result**. The function is just a different *execution host* for the validation method; the contract does not change. The Lambda receives the inputs it needs and returns a list of per-resource results: ```python def handler(event, _context): resources = event["resources"] # pre-fetched authoritative state results = [] for r in resources: # custom logic: e.g., no IAM role grants standing admin AND wildcard resource violates = grants_admin(r) and has_wildcard_resource(r) results.append({ "assertion_id": "aws_iam_no_standing_admin_wildcard", "status": "FAIL" if violates else "PASS", "resource_id": r["role_name"], "reason": ("Role grants admin on '*'" if violates else "Role scoped within least privilege"), "snapshot": {"policies": r.get("attached_policies", [])}, "observed_at": event["observed_at"], "source": "aws:iam:roles", }) return {"assertion_id": "aws_iam_no_standing_admin_wildcard", "results": results} ``` The orchestrator invokes the function on cadence, captures the returned JSON as evidence, and feeds it into the same roll-up as every other check. Treat the function's own failure to execute (timeout, error) as a *broken validation* — a vulnerability, covered below — not a passing result. A check that did not run is never a pass. ### 5. Terraform / IaC static analysis check An IaC check analyzes infrastructure-as-code to validate a control *before deploy* — catching a misconfiguration in the pull request instead of in production. The input is parsed Terraform (or CloudFormation, Bicep, etc.); the predicate asserts a required property on a resource block. This serves Change Management ("baseline defined as code") and Cloud Native Architecture. Input — a parsed Terraform resource: ```json { "type": "aws_s3_bucket", "name": "evidence", "block": { "server_side_encryption_configuration": { "rule": { "apply_server_side_encryption_by_default": { "sse_algorithm": "aws:kms" } } } }, "file": "infra/storage.tf", "line": 14 } ``` Validation logic — every S3 bucket resource declares KMS encryption: ```python def tf_bucket_requires_kms(block: dict) -> bool: rule = (block.get("server_side_encryption_configuration", {}).get("rule", {})) default = rule.get("apply_server_side_encryption_by_default", {}) return default.get("sse_algorithm") == "aws:kms" ``` The structured result points at the *file and line*, so a failed IaC check links straight to a code fix: ```json { "assertion_id": "tf_s3_encryption_required", "status": "FAIL", "resource_id": "aws_s3_bucket.evidence", "reason": "Bucket lacks KMS encryption block", "snapshot": { "file": "infra/storage.tf", "line": 14 }, "observed_at": "2026-06-04T11:03:00Z", "source": "scm:terraform" } ``` The same machine-readable result that fails the check can also drive a remediation proposal: the file path and line are enough to open a fix branch. An agent or pipeline reads the failing result, generates the missing encryption block, and opens a pull request scoped to that repo — turning a finding into a reviewable change. ### 6. Application source-code analysis check A source-code check scans application code or config for a required property — a security header set, TLS enforced, a debug flag off, a secret not hard-coded. The input is the parsed file or a structured match; the predicate asserts presence or absence. This commonly supports Service Configuration and IAM (for example, verifying the app enforces authentication on a route). Input and logic — a web config must enforce HSTS: ```python def enforces_hsts(parsed_config: dict) -> bool: headers = parsed_config.get("security_headers", {}) hsts = headers.get("Strict-Transport-Security", "") return "max-age=" in hsts and int(_max_age(hsts)) >= 31536000 # >= 1 year ``` Result — a `PASS`/`FAIL` per file, with the offending file in the snapshot: ```json { "assertion_id": "code_enforces_hsts", "status": "PASS", "resource_id": "app/middleware/security.py", "reason": "HSTS set, max-age >= 1y", "snapshot": { "header": "max-age=31536000; includeSubDomains" }, "observed_at": "2026-06-04T11:03:30Z", "source": "code:security_headers" } ``` Source-code checks are the most likely to need exclusions (test fixtures, vendored code). Handle that with the check object's per-environment enable/disable and a `resource_filter` that excludes non-applicable files *before* evaluation — never by weakening the predicate, which would mask real failures everywhere. ## What is the output contract for a KSI check? Every check, regardless of type, emits the same result object so that one aggregator can roll them all up. The contract has a machine-readable core and a human-readable layer, and it carries the metadata 20x requires: a source and a timestamp, so the assertion is reproducible and attributable. ```json { "assertion_id": "aws_cloudtrail_logs_enabled", // stable check identity "ksi_id": "KSI-MLA-LOG", // the KSI it serves "status": "PASS", // PASS | FAIL | ERROR | N/A "resource_id": "org-trail", // what was checked "reason": "Trail org-trail is logging to CloudWatch", // human-readable "snapshot": { "is_logging": true }, // evidence captured "severity": "high", "source": "aws:cloudtrail:trails", // where it came from "observed_at": "2026-06-04T11:02:11Z" // when (reproducibility) } ``` `status` is the machine layer; `reason` is the human layer; `source` + `observed_at` make it [machine-readable OSCAL](/blog/20x/ssp-to-oscal-guide)-friendly and regenerable. Note what is *not* here: no image, no PDF, no screenshot. A screenshot cannot be diffed, queried, or re-verified, so it cannot be your system of record under 20x. ### How do results roll up to a KSI assertion? Roll-up is deterministic and happens in two stages. First, the per-resource results for one assertion collapse into a verdict — passing count over total. Second, the assertion verdicts for a KSI aggregate into the KSI's pass/fail status. Keep the arithmetic explicit so an assessor can reproduce it. ```python def roll_up_assertion(results: list[dict]) -> dict: scored = [r for r in results if r["status"] in ("PASS", "FAIL")] total = len(scored) passing = sum(1 for r in scored if r["status"] == "PASS") score = (passing / total) if total else None if score is None: status = "no_evidence" elif score >= 0.75: status = "passing" elif score > 0.0: status = "partial" else: status = "failing" return {"assertion_id": results[0]["assertion_id"], "status": status, "score": score, "passing": passing, "total": total, "failing_resources": [r for r in scored if r["status"] == "FAIL"]} ``` Two aggregation modes cover most KSIs. **Per-resource** sums passing/total across every resource — right for "all production buckets encrypted." **By-provider** marks a provider covered if any of its resources passes, then scores covered-providers over connected-providers — right for "at least one cloud enforces this control." A KSI assertion is then `passing` only when its underlying verdicts clear the threshold, and the program-level summary is the weighted roll-up across KSI families. Disabled checks contribute nothing to the denominator — they produce no result, so they neither pass nor fail; the scoping decision lives in the audit trail instead. Weighting automated families more heavily than document-only families is a reasonable refinement, but the floor is this transparent passing/total math. ### How do cadence and failure-as-vulnerability work? Cadence is policy attached to the check, derived from impact level and whether the resource is machine- or non-machine-based. For machine-based resources, FedRAMP 20x requires validation at least every 7 days at Low and every 3 days at Moderate; non-machine validations must run at least once every 3 months. These are floors — a scheduler that beats them (many teams validate machine-based checks continuously) is compliant; one that drifts past them is not. We go deeper on this in our note on [KSI validation cadence](/blog/20x/fedramp-20x-ksi-validation). The failure path is the part teams most often get wrong. Under FedRAMP 20x, both a *failed* validation and a *broken* validation are vulnerabilities. A check that returns `FAIL` opens a tracked finding routed to its owner. A check that fails to *run* — the Lambda timed out, the API credential expired, the collector crashed — is equally a vulnerability, because a pipeline that silently stops collecting is an open, undetected gap. Both must flow into Vulnerability Detection and Response with the `assertion_id`, the affected resource, and an owner — never a silent retry that hides the gap. ```python def to_vulnerability(result: dict, owner: str) -> dict: assert result["status"] in ("FAIL", "ERROR") # FAIL = condition unmet; ERROR = broken run return {"source": "ksi_validation", "assertion_id": result["assertion_id"], "ksi_id": result["ksi_id"], "resource_id": result.get("resource_id"), "severity": result.get("severity", "moderate"), "owner": owner, "detected_at": result.get("observed_at"), "kind": "validation_failure" if result["status"] == "FAIL" else "broken_validation"} ``` Because every result carries a stable `assertion_id`, the vulnerability links back to exactly the check that produced it, and re-enabling a previously disabled check cleanly reopens any findings that were cascade-dismissed. Stable identity, again, is what makes the whole loop auditable. ## Frequently asked questions ### What is a FedRAMP 20x KSI check? A KSI check is a single validation that asserts one condition about your cloud service offering and emits a structured pass/fail result tied to a Key Security Indicator. Implemented as a first-class object, it has a stable identity, declared inputs, a validation method, a result, a cadence, an owner, and a failure path. Each check maps to one assertion so it can be enabled, disabled, scheduled, and attributed independently. ### Why model KSI checks as first-class objects instead of scripts? Because 20x evidence must be regenerable on demand, attributable, and auditable, and anonymous script logic cannot deliver that. A first-class check is addressable: you can list it, reference it from a finding, disable it per environment with a recorded reason, and reproduce its result with a source and timestamp. It also makes custom and agent-suggested checks a natural extension rather than a rewrite. ### What fields should a KSI check object have? Seven: identity (a stable `assertion_id`, the KSI it serves, provider, severity), inputs (the signal it reads), validation method (the predicate plus pass/fail messages), result (the structured per-resource output), cadence (how often it runs), owner (who remediates), and failure path (route to VDR). Identity and method belong to the check definition; cadence and owner are configuration layered on top. ### How often must KSI checks run? For machine-based information resources, at least every 7 days at Low and every 3 days at Moderate; the High cadence is expected to be more frequent but is not yet finalized. Non-machine-based validations must run at least once every 3 months. These are minimum frequencies — validating machine-based checks continuously is common and compliant. ### What happens when a KSI check fails or can't run? Both are vulnerabilities under FedRAMP 20x. A `FAIL` result opens a finding routed to the check's owner through Vulnerability Detection and Response. A check that errors or stops running is also a vulnerability, because a pipeline that silently stops collecting is an undetected gap. Carry the `assertion_id`, affected resource, and owner into the VDR record rather than retrying silently. ### Can a KSI check output a screenshot as evidence? No — not as the system of record. FedRAMP 20x evidence must be machine- and human-readable and regenerable on demand, and screenshots cannot be diffed, queried, or re-verified. A check should emit a structured result with a machine-readable status, a human-readable reason, an evidence snapshot, a source, and a timestamp. Screenshots can illustrate context for a human but cannot be the evidence. ### How do individual check results become a KSI pass/fail? In two deterministic stages. Per-resource results collapse into an assertion verdict (passing over total); assertion verdicts aggregate into the KSI's status, either per-resource (sum across resources) or by-provider (covered providers over connected providers). The KSI is passing only when its verdicts clear the threshold, and the program score is the weighted roll-up across KSI families. Disabled checks contribute nothing to the denominator. ### How do I add a custom KSI check? Add a new entry to your check catalog with a new `assertion_id`, the KSI it serves, its input signal, and a predicate — the same contract as every built-in check. For logic that does not reduce to a one-line predicate, host it in a serverless function that returns the standard result shape. Because the object model is uniform, the new check flows through the same roll-up, cadence, and failure handling without engine changes. ## Sources - [FedRAMP 20x Key Security Indicators — fedramp.gov](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [FedRAMP 20x Persistent Validation and Assessment — fedramp.gov](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [FedRAMP 20x Phase One Pilot Participation Example — fedramp.gov](https://www.fedramp.gov/20x/phase-one/example/) - [FedRAMP RFC-0006: 20x Phase One Key Security Indicators — fedramp.gov](https://www.fedramp.gov/rfcs/0006/) - [NIST SP 800-53 Rev 5 (control catalog) — csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) --- _Last updated: June 2026. Written by the Boundera team._ ### FIPS 140-3 Validated Cryptography: What FedRAMP Requires - URL: https://boundera.io/blog/rev5/fedramp-fips-validated-crypto - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:39Z - Reading time: 8 minutes - Main question: What does FedRAMP require for FIPS 140-validated cryptography? - TL;DR: FedRAMP requires a NIST CMVP FIPS 140-validated cryptographic module wherever federal data is encrypted at rest or in transit; the current standard is FIPS 140-3. As of September 21, 2026, FIPS 140-2 modules move to the Historical list and may be used for existing systems only. 'FIPS-compliant' is not a recognized status, and non-validated cryptography is treated by NIST as unprotected plaintext. - Excerpt: FedRAMP requires FIPS 140-validated cryptographic modules wherever federal data is encrypted. Here's what FIPS 140-3 validation means and how to verify it. # FIPS 140-3 Validated Cryptography: What FedRAMP Requires FedRAMP requires that every place your system uses cryptography to protect federal data, you use a cryptographic module that has been **validated** by NIST's Cryptographic Module Validation Program (CMVP) — not merely a module that *claims* to use approved algorithms. The current standard is **FIPS 140-3**. FIPS 140-2 modules are being sunset: as of **September 21, 2026**, CMVP moves all FIPS 140-2 certificates to the Historical list, where they may be used for existing systems only — never new ones. If a module isn't on the CMVP active validation list, NIST treats the data it "protects" as unprotected plaintext. **Key takeaways** - FedRAMP requires **FIPS 140-validated** cryptographic modules wherever federal data is encrypted at rest or in transit; the active standard is **FIPS 140-3**. - "FIPS-validated" means a module holds a CMVP certificate you can look up by number. "FIPS-compliant" is a marketing phrase with no standing — NIST does not recognize it. - As of **September 21, 2026**, FIPS 140-2 certificates move to the **Historical** list: usable for existing systems only, not new authorizations. - A module is validated for a specific **version and operational environment**. Run a different build, and you are outside the validation boundary. - Verify every certificate yourself on **csrc.nist.gov**; algorithm validation (CAVP) alone is not module validation. ## What does FedRAMP require for cryptography? FedRAMP requires that all cryptography used to protect federal information be performed by a **FIPS 140-validated cryptographic module**. This flows directly from federal law: under the relevant NIST standards, U.S. agencies must use validated cryptographic modules whenever they require information to be cryptographically protected. FedRAMP, as the program that authorizes cloud services for federal use, inherits and enforces that requirement through the NIST SP 800-53 control baseline. The control most cloud service providers (CSPs) cite is **SC-13, Cryptographic Protection**, which requires that cryptographic uses comply with applicable federal standards — meaning FIPS 140-validated modules. Related controls reinforce it: **SC-8** (transmission confidentiality and integrity) for data in transit, **SC-28** (protection of information at rest) for data at rest, and **IA-7** (cryptographic module authentication). Across all of them, the operative word is *validated*. NIST is blunt about the consequence of skipping validation. In CMVP's own words, **non-validated cryptography is viewed as providing no protection to the information** — the data is, in effect, considered unprotected plaintext. That is why an assessor will not accept "we use AES-256" as evidence. They will ask which module performs that AES-256, and for its CMVP certificate number. > Source: [NIST CMVP — "if cryptography is required, then it must be validated"](https://csrc.nist.gov/projects/cryptographic-module-validation-program) ## What is FIPS 140-3 validation? FIPS 140-3 (*Security Requirements for Cryptographic Modules*) is the federal standard that defines what a cryptographic module must do to be trusted for protecting sensitive government information. Validation is the formal process, run by NIST and the Canadian Centre for Cyber Security through the CMVP, of testing a module against that standard and issuing a certificate. The process works like this: 1. An accredited, independent **Cryptographic and Security Testing Laboratory (CSTL)** tests the module against FIPS 140-3 and its supporting publications (the SP 800-140 series). 2. The lab submits a report to CMVP, which reviews it and, if it passes, issues a numbered **validation certificate**. 3. The certificate lists the exact module name, version, security level, and the **operational environment(s)** in which the validation holds. CMVP began accepting FIPS 140-3 submissions on **September 22, 2020**, and stopped accepting new FIPS 140-2 submissions after **September 21, 2021**. A FIPS 140-3 validation stays on the **Active** list for five years (two years for interim validations) and may be used for new and existing systems during that window. > Source: [NIST CMVP Overview — validation timeline and applicability](https://csrc.nist.gov/projects/cryptographic-module-validation-program) ## What is the difference between FIPS-validated and FIPS-compliant? This is the single most expensive misunderstanding in FedRAMP cryptography. **FIPS-validated** means the module has an actual CMVP certificate you can verify. **FIPS-compliant** is a vendor phrase that usually means "we implemented FIPS-approved algorithms" — but implementing an approved algorithm is not the same as having the module that runs it tested and certified. NIST does not recognize "compliant" as a status, and FedRAMP assessors do not accept it. | Attribute | FIPS 140 validated | "FIPS compliant" / "FIPS capable" | | --- | --- | --- | | Has a CMVP certificate number | Yes — verifiable on csrc.nist.gov | No | | Independently tested by an accredited CSTL | Yes | Not necessarily | | Recognized by NIST and FedRAMP | Yes | No — not a NIST status | | Acceptable as 3PAO evidence | Yes | No | | What it actually guarantees | The module, at a stated version and environment, met FIPS 140 | Only that an approved algorithm appears in the product | NIST's guidance makes the trap explicit: a product **does not meet** the FIPS 140 requirements "by simply implementing an approved security function and acquiring algorithm validation certificates." Algorithm validation (through the Cryptographic Algorithm Validation Program, CAVP) is a *prerequisite* for module validation — but on its own it does not make a module validated. If a vendor offers a CAVP certificate and calls the product "FIPS compliant," that is not enough for FedRAMP. > Source: [NIST CMVP — Validated Modules guidance](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules) ## Where do you need FIPS-validated crypto in a FedRAMP system? You need a validated module everywhere federal data is cryptographically protected. In practice that means three domains: **data at rest**, **data in transit**, and the **key management** that supports both. The table below maps the common touchpoints. | Domain | Where it shows up | Relevant control | What an assessor checks | | --- | --- | --- | --- | | Data in transit | TLS for web/API traffic, VPN tunnels, internal service-to-service encryption | SC-8 | The TLS/VPN endpoint uses a validated module; certificate covers the running version | | Data at rest | Disk/volume encryption, database and object-storage encryption, backups | SC-28 | The storage encryption engine is a validated module, not just "AES on" | | Key management | Key generation, storage, and protection (often an HSM or KMS) | SC-12, SC-13 | The KMS/HSM module holds a current CMVP certificate at the right environment | | Authentication | Cryptographic authenticators, MFA secrets, password hashing | IA-7 | Authentication crypto is performed by a validated module | A useful instinct: anywhere your SSP narrative says "encrypted," ask *by which module, and what is its certificate number?* If you can't answer that for a given data flow, that flow is a finding waiting to happen. For a refresher on how these claims land in your authorization package, see our [FedRAMP documentation explained](/blog/rev5/fedramp-documentation-ssp-sap-sar-poam) guide. ## How do you verify a module is actually validated? Don't take a vendor's word for it — look the certificate up yourself on the CMVP validated-modules search. Follow these steps for every cryptographic module in your boundary: 1. **Get the certificate number** from the vendor, in writing. NIST recommends asking the vendor for a signed letter stating the product *is* a validated module or *embeds* one, that the module provides all cryptographic services in the solution, and citing the certificate number. 2. **Search csrc.nist.gov** for that number and confirm the module name and vendor match what you're actually running. 3. **Check the status.** The certificate must be on the **Active** list. If it's **Historical**, it is for existing systems only; if it's **Revoked**, it cannot be referenced for compliance at all. 4. **Match the version and operational environment.** The certificate states the exact validated version, part number, and the operating system / platform it was tested on. If you run a different build or a different OS, you may be outside the validation. This verification step is where Boundera's evidence automation earns its keep. Instead of a consultant chasing certificate numbers across a dozen vendors before an assessment, the platform inventories the cryptographic modules in your cloud configuration, ties each to its CMVP certificate, and flags any that are Historical, Revoked, or running a version the certificate doesn't cover. If you're moving toward the new program model, the same approach feeds machine-readable evidence — see how we [automate KSI evidence](/blog/20x/fedramp-20x-ksi-evidence-automation) for FedRAMP 20x. ## What are the common FIPS validation pitfalls? The findings repeat themselves across CSPs. The most common are: - **Treating "FIPS-compliant" as good enough.** A product that implements approved algorithms but has no module certificate is not validated. This is the number-one mistake. - **Running the wrong version.** The module is validated at a specific version; if you upgrade past it (or run an older build), you've stepped outside the validated boundary. Patches matter. - **Wrong operational environment.** A module validated on one OS or platform is not automatically validated on another. Software/firmware modules have porting guidance, but you must follow it — assuming portability is risky. - **Relying on a Historical or Revoked certificate.** A Historical module cannot back a *new* system; a Revoked one cannot be used at all. With the **September 21, 2026** FIPS 140-2 sunset, modules you relied on last year may now be Historical. - **Enabling the product but not FIPS mode.** Many products ship a validated module that only operates in the validated configuration when "FIPS mode" is explicitly turned on. Default settings often are not the validated mode. - **Confusing CAVP algorithm certificates with module validation.** Algorithm validation is necessary but not sufficient; only the *module* certificate counts. Each of these turns into an SC-13 or SC-28 finding, then a POA&M item, and sometimes a schedule slip while you swap in a validated module. The fix is almost always cheaper before the assessment than after. ## How does the 2026 FIPS 140-2 sunset affect FedRAMP? It moves the goalposts for new authorizations. Through **September 21, 2026**, a CSP could still rely on FIPS 140-2 validated modules for new systems. After that date, CMVP places all FIPS 140-2 certificates on the **Historical** list — meaning they are acceptable for *existing* systems only. Any system pursuing a new FedRAMP authorization should be standing on **FIPS 140-3** validated modules. If your environment still depends on FIPS 140-2 modules, treat the migration as a real project: inventory where those modules live, check whether the vendor has a FIPS 140-3 replacement validated and on the Active list, and plan the swap before it blocks an authorization. CMVP's own guidance is to keep using FIPS 140-2 modules until FIPS 140-3 replacements become available — but for *new* systems, that runway closed in September 2026. For the full lifecycle context, see our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025). ## Frequently asked questions ### Does FedRAMP require FIPS 140-2 or FIPS 140-3? FedRAMP requires a FIPS 140-validated module, and the current standard is **FIPS 140-3**. FIPS 140-2 modules were valid for new systems only through **September 21, 2026**; after that they move to the Historical list and can support existing systems only. New FedRAMP systems should use FIPS 140-3 validated modules. ### Is "FIPS-compliant" acceptable for FedRAMP? No. "FIPS-compliant" is not a NIST-recognized status. FedRAMP requires a **FIPS-validated** module with a CMVP certificate you can verify. NIST states that implementing an approved algorithm and obtaining algorithm validation does not, by itself, make a module FIPS 140 validated. ### What happens if I use a non-validated cryptographic module? NIST considers non-validated cryptography to provide **no protection** — the data is treated as unprotected plaintext. For FedRAMP, that means a control failure (typically SC-13 or SC-28), a finding in the SAR, and a POA&M item until you replace the module with a validated one. ### Where can I check if a module is FIPS-validated? On NIST's CMVP validated-modules search at **csrc.nist.gov**. Search by certificate number or vendor, confirm the module name and version match what you run, and check that the certificate is on the **Active** list rather than Historical or Revoked. ### Is algorithm validation (CAVP) the same as module validation? No. CAVP validates individual algorithms and is a prerequisite for module validation, but a module is only "validated" when it holds a CMVP certificate. A vendor offering only CAVP certificates has not demonstrated a FIPS 140 validated module. ### Does the module version matter? Yes. A CMVP certificate validates a specific module **version and operational environment**. Running a different build, a different OS, or a patched version not covered by the certificate can place you outside the validation boundary, which an assessor will treat as non-compliant. ### Where in my system do I need validated crypto? Anywhere federal data is encrypted — data **in transit** (TLS, VPNs), data **at rest** (disk, database, object storage, backups), the **key management** behind them (KMS/HSM), and cryptographic **authentication**. Map each "encrypted" claim in your SSP to a specific validated module and its certificate. ### Do I need to turn on a "FIPS mode"? Often, yes. Many products include a validated module but only operate in the validated configuration when FIPS mode is explicitly enabled. Default settings frequently are not the validated mode, so confirm and document that FIPS mode is active. ## Sources - [NIST — Cryptographic Module Validation Program (CMVP) overview](https://csrc.nist.gov/projects/cryptographic-module-validation-program) - [NIST — CMVP Validated Modules search and guidance](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules) - [FIPS 199 — Standards for Security Categorization (NIST)](https://csrc.nist.gov/pubs/fips/199/final) - [FedRAMP — official program site](https://www.fedramp.gov/) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP for Startups: Is It Worth It, and When to Start - URL: https://boundera.io/blog/20x/fedramp-for-startups - Program: FedRAMP 20x and Rev 5 - Category: Getting Started - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:38Z - Reading time: 9 minutes - Main question: Is FedRAMP worth it for a startup, and when should you start? - TL;DR: FedRAMP is worth it for a startup only when a federal agency is buying, or about to. Start the certification process once federal demand is real, but build a clean cloud-native architecture from day one. FedRAMP 20x and its sponsorless Program Certification path lowered the barrier dramatically: pilot participants reached certification in under two months, and Boundera's analysis puts a 20x Low (Class B) effort around $100K-$300K versus ~$250K-$500K for a traditional Low. - Excerpt: Is FedRAMP worth it for a startup, and when should you start? How 20x and the sponsorless path lower the barrier for lean cloud-native teams in 2026. # FedRAMP for Startups: Is It Worth It, and When to Start FedRAMP is worth it for a startup only when a federal agency is actually buying, or is about to. The certification is a sales unlock, not a security badge, so the right time to start is when you have a federal opportunity in hand (or a credible pipeline) rather than as a speculative bet. The good news for lean teams in 2026: FedRAMP 20x and its sponsorless Program Certification path have lowered the barrier dramatically, with pilot participants reaching certification in under two months and Boundera's analysis putting a 20x Low (Class B) effort around $100K-$300K versus roughly $250K-$500K for a traditional Low. **Key takeaways** - Pursue FedRAMP when federal revenue is the gate, not before. No agency demand means no payback. - FedRAMP 20x removes the agency-sponsor requirement for qualifying cloud-native services through the new Program Certification path, which is the single biggest unlock for startups. - Boundera's cost framing: traditional Low runs ~$250K-$500K; a 20x Low (Class B) effort runs ~$100K-$300K. Most startups should not target High (Class D). - FedRAMP's pilot participants reached certification in under two months from start, versus years on the legacy path. - The real startup cost is engineering and evidence automation time, not a fee paid to FedRAMP. FedRAMP charges cloud providers nothing. ## Should a startup pursue FedRAMP? Pursue FedRAMP when a federal agency is the buyer holding up a deal, or when federal sales are a deliberate part of your near-term growth plan. Skip it, or defer it, when your revenue is entirely commercial and no government customer has asked. FedRAMP is a market-access requirement, not a general security improvement program. Agencies cannot operate most cloud services without a FedRAMP path, so for a startup the question is narrow: is federal money on the table, and is it large enough to justify the work? If the answer is yes, FedRAMP becomes one of the highest-leverage investments you can make because it opens a buyer that commercial competitors cannot reach. If the answer is no, the same time and money is almost always better spent elsewhere. Two failure modes are common. The first is starting too early, building toward certification with no agency demand and watching the effort stall. The second is starting too late, getting a federal opportunity and then discovering certification will take longer than the procurement window allows. The path between those mistakes is to treat FedRAMP as demand-driven: move when you can name the buyer or the pipeline, and prepare your architecture before that so you can move quickly when demand appears. For a deeper buyer-side decision, see our guide on whether you [do you actually need FedRAMP](/blog/20x/do-you-need-fedramp). ## What signals tell a startup it's ready (or not)? The clearest readiness signal is a named federal opportunity combined with a cloud-native architecture you can evidence automatically. The clearest "not yet" signal is the absence of either. | Signals you're ready to start | Signals to wait | | --- | --- | | A federal agency has asked for FedRAMP, or a concrete pipeline exists | No government buyer has surfaced; interest is hypothetical | | Your service is cloud-native and runs on FedRAMP Certified infrastructure (e.g., authorized IaaS/PaaS) | You run your own datacenters or non-cloud-native infrastructure | | You target the former Low or Moderate baselines (Class B or Class C) | You would need Class D (High) for mission-critical agency use | | Engineering can produce continuous, machine-readable evidence (IaC, central logging, automated scanning) | Evidence is manual, screenshot-based, and reconstructed on demand | | You have funding or revenue to staff a multi-month effort and ongoing monitoring | Runway is too short to absorb both the project and continuous monitoring | > Source: [FedRAMP Certification - Consolidated Rules for 2026 Public Preview](https://www.fedramp.gov/preview/2026/certification/) Cloud-native architecture matters more than company size. FedRAMP describes 20x as best for cloud-native services built with modern infrastructure and security engineering practices, especially those with empowered governance, risk, and compliance engineering. A ten-person startup that already runs infrastructure-as-code, centralized logging, and automated vulnerability management is often closer to ready than a larger company with manual, ticket-driven operations. ## When is the right time to start? Start preparing your architecture early and start the formal certification process once federal demand is real. These are two different clocks, and conflating them is where startups lose time and money. The architecture clock should run from day one for any company that even might sell to government. Defining a clean boundary, keeping a living inventory, centralizing logs, and enforcing identity controls are good engineering regardless of FedRAMP, and they are exactly what a 20x assessment evidences. Doing this work as you build costs far less than retrofitting it later. The certification clock should start when you can name the buyer or the pipeline. Under the legacy model this was painful, because the traditional path "requests an agency to sponsor authorization by investing considerable resources in advance" and "typically requires years of preparation." That made timing a gamble: you often had to invest heavily before you knew an agency would commit. FedRAMP 20x changes the timing calculus because the Program Certification path "does not require an initial agency partner or sponsor," and FedRAMP reviews initial certification requests directly. A startup can now build toward certification on its own schedule and submit when ready, rather than waiting for a sponsor to fund the effort up front. ## How does FedRAMP 20x change the math for startups? FedRAMP 20x changes the math three ways: it removes the sponsor requirement, it compresses the timeline, and it lowers the cost by replacing written narratives with automated evidence. Together these turn FedRAMP from a large-enterprise project into something a funded startup can realistically pursue. The sponsorless path is the headline. FedRAMP's own comparison contrasts the legacy model, which "requests an agency to sponsor authorization by investing considerable resources in advance," with 20x, which "does not require an agency sponsor; FedRAMP reviews initial authorization requests directly." For a startup without an agency champion, that is the difference between a viable plan and a dead end. The new Program Certification path formalizes this: it lets qualifying providers submit certification packages directly to FedRAMP for FedRAMP 20x Class A, B, or C, no agency partner needed. The timeline compresses too. FedRAMP reports that "pilot participants have received FedRAMP authorization in less than two months from start," compared with the years of preparation the legacy path typically required. A shorter window means fewer consultant months, less internal opportunity cost, and a certification that can keep pace with a procurement cycle instead of missing it. Cost follows from both. Because 20x is "designed for automated demonstration of secure configurations and practices" rather than "extensive written narratives describing static security decisions," much of the expensive, labor-heavy documentation and assessment work shrinks. In Boundera's analysis, a traditional Low authorization runs roughly $250K-$500K, while a 20x Low (Class B) effort runs roughly $100K-$300K. For more detail, see our breakdown of [FedRAMP 20x cost](/blog/20x/fedramp-20x-cost). One caveat on scope: 20x in 2026 covers the former Low and Moderate baselines (now Certification Classes B and C). It is "not available to cloud service providers that run their own infrastructure or those seeking Class D (High) Certification." Most startups should target Class B or C and choose Class D only if a specific agency mission demands it. ## How much does it cost a startup? Plan for roughly $100K-$300K for a 20x Low (Class B) effort, or $250K-$500K for a traditional Low, plus continuous monitoring every year after. The exact number depends on your architecture maturity and how much evidence you can automate. | Path / level | Boundera's initial-effort estimate | Best fit | | --- | --- | --- | | FedRAMP 20x Low (Class B) | ~$100K-$300K | Cloud-native startup, lean team, sponsorless | | Traditional Low | ~$250K-$500K | Non-cloud-native, or specific agency requires legacy path | | Moderate (Class C) | Higher than Low; scales with boundary and controls | Enterprise-wide agency use, CUI handling | > Source: Boundera analysis. FedRAMP itself sets no provider fees - see [FedRAMP Certification](https://www.fedramp.gov/preview/2026/certification/). A critical point that confuses many founders: FedRAMP charges cloud providers nothing. FedRAMP "does not establish contracts or legal agreements for FedRAMP Certification." Every dollar goes to private parties - independent assessors, advisors, tooling - plus your own engineering and compliance labor. That is why estimates vary so widely and why the U.S. Government Accountability Office has noted that cost data is limited and providers measure it inconsistently. For a startup, the largest cost is usually internal engineering time, not the assessment. The cheapest programs are the ones where evidence already exists in queryable systems - cloud APIs, identity providers, scanners, CI/CD - so the team is wiring up automation rather than manufacturing documentation. For a full lifecycle view, see our [FedRAMP cost](/blog/20x/fedramp-cost-2026) breakdown. ## How can a lean team make FedRAMP feasible? A lean team makes FedRAMP feasible by treating evidence as a product of the system rather than a manual artifact, so a handful of engineers can sustain certification without a large compliance department. This is the core reason 20x exists, and it is where automation pays off. Under 20x, security state is "automatically enforced, monitored, and reported" through Key Security Indicators that are continuously validated. Machine-based resources must be validated at least every 7 days at Low and every 3 days at Moderate, with non-machine validations at least every 3 months. No startup can sustain that cadence with screenshots and spreadsheets. It requires connecting evidence sources where the truth already lives and letting the pipeline produce current results on schedule. This is where a platform like Boundera is meant to help: not by generating prettier documents, but by turning a small team's existing cloud, identity, and scanning data into continuously validated KSI evidence, and by turning failed validations into specific, ownable engineering work. The startups that succeed at FedRAMP are not the ones with the biggest compliance teams. They are the ones whose systems keep producing fresh evidence on their own, so two or three engineers can carry a certification that used to require a department. ## Frequently asked questions ### Is FedRAMP worth it for an early-stage startup? It is worth it only when federal revenue is the gate. FedRAMP is a market-access requirement, not a security upgrade, so the payback comes entirely from agency deals you cannot win without it. If no government buyer has surfaced, the time and money is almost always better spent on commercial growth, with your architecture kept clean so you can move fast later. ### Do startups still need an agency sponsor for FedRAMP? Not for qualifying cloud-native services. The FedRAMP 20x Program Certification path lets providers submit certification packages directly to FedRAMP for Class A, B, or C without an initial agency partner or sponsor. The traditional Agency Certification path still exists and remains the only route to Class D (High). ### How long does FedRAMP take for a startup in 2026? FedRAMP reports that 20x pilot participants received certification in under two months from start, a dramatic change from the years of preparation the legacy path typically required. Your real timeline depends on how ready your engineering is to produce continuous, machine-readable evidence before you submit. ### How much does FedRAMP cost a startup? In Boundera's analysis, a 20x Low (Class B) effort runs roughly $100K-$300K and a traditional Low runs roughly $250K-$500K, plus continuous monitoring each year after. FedRAMP itself charges no fee; costs go to assessors, tooling, advisors, and your own engineering time, which is usually the largest line item. ### Which FedRAMP class should a startup target? Most startups should target Class B (the former Low baseline) or Class C (the former Moderate baseline), and choose based on how agencies will use the service and what data it handles. Class D (High) is for mission-critical use, is not available under 20x, and is rarely the right first target for a startup. ### Can a startup get FedRAMP without a dedicated compliance team? Yes, if its architecture produces evidence automatically. Cloud-native startups with infrastructure-as-code, centralized logging, and automated scanning can sustain 20x validation with a few engineers, because KSI evidence is generated continuously by the system rather than assembled by hand. Manual, screenshot-based operations are what force large compliance teams. ### What should a startup do before any federal demand appears? Build a clean authorization boundary, keep a living inventory, centralize logging, enforce strong identity controls, and connect automated vulnerability scanning - all good engineering regardless of FedRAMP. Doing this as you build means that when an agency opportunity appears, you can start the certification clock immediately instead of retrofitting your system under deadline pressure. ### Is FedRAMP 20x available for all startups? No. FedRAMP 20x is for cloud-native commercial services built on FedRAMP Certified infrastructure and platforms. It is not available to providers that run their own infrastructure or to those seeking Class D (High), who must use the traditional Rev5 path instead. ## Sources - [FedRAMP 20x Overview - fedramp.gov](https://www.fedramp.gov/20x/) - [FedRAMP Certification - Consolidated Rules for 2026 Public Preview](https://www.fedramp.gov/preview/2026/certification/) - [Getting Started as a Cloud Service Provider - fedramp.gov](https://www.fedramp.gov/preview/2026/providers/start/) - [U.S. GAO - Cloud Security: Federal Authorization Program (FedRAMP)](https://www.gao.gov/products/gao-24-106591) --- _Last updated: June 2026. Written by the Boundera team._ ### Do You Actually Need FedRAMP? A 2026 Decision Guide - URL: https://boundera.io/blog/20x/do-you-need-fedramp - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:37Z - Reading time: 9 minutes - Main question: Do you actually need FedRAMP? - TL;DR: You need FedRAMP if a federal agency intends to use your cloud service to handle sensitive (non-public) federal information under a shared-responsibility model, per OMB M-24-15. If you sell only commercially, or an agency uses your service only for public/non-sensitive data, you don't. Only the agency can make the final scope determination. - Excerpt: Do you need FedRAMP? A 2026 decision guide using OMB M-24-15 scope rules - who needs it, when it's not required, alternatives, cost, and how to decide. # Do You Actually Need FedRAMP? A 2026 Decision Guide You need FedRAMP if a federal agency intends to use your cloud service in a way that falls within the **scope of FedRAMP** as defined by [OMB Memorandum M-24-15](https://www.fedramp.gov/docs/authority/m-24-15/scope/) — generally, when your service stores, processes, or transmits **sensitive (non-public) federal information** under a shared-responsibility model. If you sell only to commercial customers, or an agency uses your service only for public or non-sensitive information, you almost certainly do **not** need FedRAMP. Crucially, only a federal agency — not the vendor — can make the final scope determination for its specific use case. **Key takeaways** - FedRAMP is triggered by the **agency's use case**, not by the product itself. The same cloud service can be in scope for one agency and out of scope for another. - The official 2026 test comes from M-24-15: does the service handle **sensitive federal information** under a **shared-responsibility model** that other agencies could reasonably reuse? If yes to the [scope indicators](https://www.fedramp.gov/docs/authority/scope/), it is in scope. - M-24-15 names explicit out-of-scope categories: single-agency systems, public social media, search engines, commercial information providers, and negligible-risk services. - As of February 2026, FedRAMP uses a single label — **FedRAMP Certified** — for every authorization, replacing older terms. Baselines are now described as **Certification Classes A, B, C, and D** ([NTC-0004](https://www.fedramp.gov/notices/0004)). - If federal agencies are not in your addressable market, pursuing certification is rarely worth the time and cost. ## Who needs FedRAMP? You need a FedRAMP authorization if you are a cloud service provider (SaaS, PaaS, or IaaS) and a federal agency wants to use your service to handle sensitive federal information. Per FedRAMP's own guidance, *"any company selling a cloud service to the government that meets the criteria outlined in the scope of FedRAMP must obtain a FedRAMP authorization."* M-24-15 establishes four **scope indicators** an agency reviews before deciding whether FedRAMP applies. Your service is in scope when the agency answers **yes** to all of these: | Scope indicator (from M-24-15) | Plain-language meaning | | --- | --- | | Handles sensitive federal information | The service stores, processes, or transmits non-public information the agency must protect under 44 U.S.C. § 3506. | | Requires an agency-specific tenant or centralized administration | The agency configures and maintains its own controlled environment within the service. | | Integrates with agency enterprise security | The service plugs into identity, SIEM, single sign-on, or similar enterprise security functions. | | Reusable across agencies | Other agencies could reasonably be expected to adopt the same service. | > Source: [Scope of FedRAMP Guidelines and Examples — FedRAMP.gov](https://www.fedramp.gov/docs/authority/scope/) (mandated by OMB M-24-15) One nuance worth internalizing: FedRAMP does not publish a list of services that are always in or always out of scope, precisely because the same product can land on either side depending on how an agency uses it. That is why the determination belongs to the agency, with the vendor referencing the guidance to anticipate demand. ## When is FedRAMP NOT required? FedRAMP is not required when an agency's use of your service does not involve sensitive federal information or a shared-responsibility model that other agencies would need to authorize. M-24-15 calls out five exclusion categories where authorization is generally **not** needed: - **Single-agency systems** — software operated by or on behalf of one agency on its own cloud infrastructure, not offered as a shared service. (Example from FedRAMP: GSA's public Data.gov is out of scope; a shared managed platform like USDA's AMPS is in scope.) - **Social media and communications** — public-facing accounts and posts used per agency social media policy, where all information is intended for public use. - **Search engines** — public web search and public AI chatbots used only with public or non-sensitive information. - **Information providers** — widely available commercial services that supply information but do not collect or retain federal information (maps, online learning, address verification, business intelligence). - **Negligible-risk services** — ancillary tools whose compromise would have an insignificant effect, such as basic CAPTCHA, public uptime monitoring, and font libraries. The dividing line in every category is **sensitivity** and **retention**. An AI coding assistant on a *public* repository is out of scope; the same assistant on a *private, controlled* repository is in scope. A monitoring tool that pings a *public* endpoint is out of scope; an APM agent with *privileged access to internal systems* is in scope. If you sell exclusively to commercial, state, or local customers and have no federal agency use case, FedRAMP does not apply to you at all — the program is limited by law to cloud services used by federal agencies. ## Should I pursue FedRAMP? A scenario decision table Use the table below to pressure-test your own situation. These are illustrative scenarios; the authoritative determination still rests with the contracting agency. | Scenario | Need FedRAMP? | Why | | --- | --- | --- | | SaaS storing agency Controlled Unclassified Information (CUI) in a dedicated tenant | Yes | Sensitive federal information + shared responsibility + reusable across agencies. | | Selling only to commercial enterprises, no federal customers | No | FedRAMP applies only to cloud services used by federal agencies. | | Public-facing agency website you host on infrastructure you also authorize end-to-end | Likely no (single-agency) | Operated for one agency, no shared-responsibility model others must authorize. | | AI assistant operating on a private, access-controlled federal code repository | Yes | Service can expose sensitive, strictly controlled federal information. | | AI assistant operating only on fully public code | No | Information is already public; treated like a search tool. | | Identity-proofing service that collects and stores citizen PII for an agency | Yes | Collects and maintains sensitive federal PII on the agency's behalf. | | Address-verification API that returns match/no-match and discards the data | No | Temporarily processes data, retains nothing; an information provider. | | Public uptime monitor pinging a non-critical public API | No | Negligible risk; measures public endpoints only. | | You expect federal demand in 12–24 months and want to be procurement-ready | Strategic yes | Certification is a business-development driver and shortens future sales cycles. | ## What does it cost to pursue FedRAMP? Pursuing FedRAMP is a multi-quarter investment in engineering, documentation, independent assessment, and ongoing continuous monitoring — not a one-time certificate. The exact figure depends on your **Certification Class** (the assessment baseline), your architecture's maturity, and whether you take the traditional Rev 5 path or a FedRAMP 20x path. We break the numbers down in our dedicated [FedRAMP cost](/blog/20x/fedramp-cost-2026) guide, and we map baselines to data sensitivity in our guide to [FedRAMP impact levels](/blog/rev5/fedramp-low-moderate-high-impact-levels). Beyond dollars, budget for three things teams routinely underestimate: - **Time.** A traditional authorization is a months-long effort spanning readiness, System Security Plan (SSP) development, independent assessment, remediation, and authorization. - **Continuous monitoring.** Authorization is not "set and forget." Authorized providers submit recurring vulnerability scans, maintain a Plan of Action and Milestones (POA&M), and complete annual assessments. - **Sponsorship.** A Rev 5 [Agency Authorization](https://www.fedramp.gov/rev5/agency-authorization/) requires a federal agency willing to sponsor and review your package. No sponsor, no agency authorization. For the full lifecycle from readiness through authorization, see our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025). ## How do you decide? Decide by answering two questions in order: **Is there a real federal agency use case for my service?** and **Does that use case put me in scope under M-24-15?** If both are yes, FedRAMP is effectively mandatory to win the business. If the first is no, stop — there is no reason to pursue it yet. A practical decision sequence: 1. **Confirm the demand.** Identify a specific agency buyer or contract. FedRAMP without a federal sales motion is sunk cost. 2. **Run the scope test.** Walk your use case through the four M-24-15 [scope indicators](https://www.fedramp.gov/docs/authority/scope/) and the five exclusion categories. Document your reasoning. 3. **Get the agency's read.** Because only the agency can make the determination, raise the question early with your prospective sponsor or contracting officer. 4. **Match data to a baseline.** Use FIPS 199 categorization to estimate which Certification Class your data sensitivity implies, then size the effort accordingly. 5. **Weigh the business case.** FedRAMP certification creates cross-government visibility on the [FedRAMP Marketplace](https://www.fedramp.gov/marketplace) and a reusable package multiple agencies can leverage — a genuine growth lever if federal is part of your strategy. ### How Boundera approaches the decision In our work helping cloud teams prepare for certification, the most expensive mistakes happen before any control is ever written — at the scope and boundary stage. We start every engagement by mapping the customer's actual data flows against the M-24-15 scope indicators, so the team knows *whether* it needs FedRAMP and *which baseline* before spending a dollar on assessment. Getting the boundary right early is the single highest-leverage decision in the entire process; an over-broad boundary inflates cost and timeline, while an under-scoped one triggers findings during assessment. ## Frequently asked questions ### Is FedRAMP legally required for all cloud vendors? No. FedRAMP applies only to cloud services used by federal agencies in a way that falls within the scope defined by OMB M-24-15. Agencies are required by law and OMB policy to use FedRAMP for in-scope cloud services, which in turn means vendors must be certified to serve those use cases. Vendors with no federal agency use case are not subject to FedRAMP. ### Who decides whether my service is in scope? The federal agency does. FedRAMP's official guidance states that only a federal agency can determine whether its use of a cloud service falls within scope. Vendors can and should reference the M-24-15 scope guidance to anticipate the answer, but the contracting or authorizing agency makes the binding call for its specific use case. ### What is the difference between "FedRAMP Certified" and the old labels? As of February 2026, FedRAMP uses a single official label — **FedRAMP Certified** (or FedRAMP Certification) — for every authorization, including both Rev 5 and 20x paths. Per NTC-0004, FedRAMP deliberately chose not to create separate designations such as "FedRAMP Validated," to avoid procurement confusion. The Marketplace provides filters to distinguish paths instead. ### What are FedRAMP Certification Classes A, B, C, and D? They are the four assessment baselines, relabeled in 2026 to avoid confusion with the DoD Impact Level system. Per NTC-0004, the labels do not change the underlying requirements — they describe the depth of information assessed. For Rev 5, Class A is a new pilot baseline, Class B covers the former LI-SaaS and Low baselines, Class C covers the former Moderate baseline, and Class D covers the former High baseline. ### Do I need FedRAMP if I only handle public federal data? Generally no. If an agency uses your service only with public or non-sensitive information — public search, public social media, public code, public endpoint monitoring — M-24-15 places that use outside FedRAMP's scope. The trigger is sensitive, non-public federal information, not federal use in general. ### Can I sell to a federal agency while pursuing FedRAMP? It depends on the agency and the use case. Some agencies allow limited use under an agency-issued authorization while a provider works toward full FedRAMP certification, but an in-scope cloud service ultimately needs FedRAMP. Confirm any interim path directly with your sponsoring agency, since the agency owns the risk decision. ### Does a FedRAMP Certification guarantee my service is approved at a given impact level? No. Per NTC-0004, a FedRAMP Certification is a reusable package of assessed materials, not a government-wide acceptance of risk at a specific FIPS 199 security category. Each agency authorizing official independently decides whether to authorize your service for a given security category under the Risk Management Framework. ### Is FedRAMP worth it for a startup with no federal customers yet? Usually not — until federal demand is real. FedRAMP can be a strong business-development driver if agencies are in your ideal customer profile, but absent a sponsor or contract it is a significant cost with no near-term return. Most early-stage teams should validate federal demand first, then pursue certification once a use case materializes. ## Sources - [Scope of FedRAMP Guidelines and Examples — FedRAMP.gov](https://www.fedramp.gov/docs/authority/scope/) - [OMB Memorandum M-24-15 (FedRAMP scope) — FedRAMP.gov](https://www.fedramp.gov/docs/authority/m-24-15/scope/) - [Authority & Responsibility (FedRAMP Authorization Act, M-24-15) — FedRAMP.gov](https://www.fedramp.gov/docs/authority/) - [NTC-0004: FedRAMP Authorization Designations (single "FedRAMP Certified" label; Certification Classes A–D) — FedRAMP.gov](https://www.fedramp.gov/notices/0004) - [Is FedRAMP Right For You? — FedRAMP.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/authorization/getting-started/) - [FedRAMP Marketplace — FedRAMP.gov](https://www.fedramp.gov/marketplace) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP Compliance Tools in 2026: What to Look For - URL: https://boundera.io/blog/20x/best-fedramp-compliance-tools-2026 - Program: FedRAMP 20x - Category: Automation - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:36Z - Reading time: 9 minutes - Main question: What should you look for in FedRAMP compliance tools in 2026? - TL;DR: The best FedRAMP tool in 2026 turns your package into living data: it evaluates controls, generates and maintains the SSP, collects evidence continuously, automates KSI validation for 20x, manages the POA&M, and emits machine-readable OSCAL across your clouds. Evaluate by capability, not by ranking, and weight by your path - 20x programs prioritize continuous KSI evidence; Rev 5 programs prioritize SSP generation and control mapping. - Excerpt: How to evaluate FedRAMP compliance tools in 2026 by capability - control mapping, SSP generation, continuous evidence, KSI automation, OSCAL, and ConMon. # FedRAMP Compliance Tools in 2026: What to Look For The best FedRAMP compliance tool in 2026 is the one that turns your authorization package into living data instead of a folder of documents — meaning it can evaluate controls, generate and maintain your SSP, collect evidence continuously, automate Key Security Indicator (KSI) validation for FedRAMP 20x, manage your POA&M, and emit machine-readable OSCAL output across the clouds you actually run on. Rather than picking from a ranked list, evaluate tools against the seven capabilities below and weight them by your path: a FedRAMP 20x provider should prioritize continuous KSI evidence and persistent validation, while a Rev 5 program should prioritize SSP generation and control mapping. Boundera is one option built specifically for this capability set, with AI control evaluation, SSP generation, and continuous KSI evidence as core features. **Key takeaways** - Evaluate **capabilities, not rankings.** The seven that matter most in 2026 are control mapping/SSP generation, continuous evidence collection, POA&M management, OSCAL output, KSI automation for 20x, continuous monitoring (ConMon), and multi-cloud coverage. - FedRAMP 20x raises the bar: evidence must be **machine-readable and regenerable on demand**, and machine-based validations must run at least every **7 days at Low and 3 days at Moderate**, so a tool that only produces point-in-time reports is no longer sufficient. - 2026 terminology matters: there is now a single **FedRAMP Certified** label and **Certification Classes A, B, C, and D** — make sure your tooling and your team speak the current language. - **Build-vs-buy** turns on opportunity cost. A homegrown evidence pipeline is achievable but rarely cheaper than buying once you account for engineering time, maintenance, and the cadence FedRAMP now requires. - The strongest tools reduce the work that consumes the most hours: **mapping each signal to the right control or KSI with defensible pass/fail criteria** and keeping that mapping current as the boundary changes. ## What should FedRAMP compliance software do? FedRAMP compliance software should do the repetitive, error-prone work that humans do badly and slowly: gathering evidence, mapping it to requirements, keeping documents current, and proving the same facts over and over on a schedule. Reviewers and assessors reward traceability and current state; they punish stale screenshots and vague narratives. A tool earns its place by making traceability automatic and current state cheap to prove. At a minimum, modern FedRAMP software should cover the full lifecycle — readiness, documentation, assessment support, and continuous monitoring after authorization — and represent your package as structured data you can validate and diff, not just as exported files. The most expensive phase of FedRAMP is not getting authorized; it is staying authorized. So the question to ask of any tool is less "does it help us write the SSP once" and more "does it keep the SSP, evidence, and POA&M true as engineers ship changes every week." Below are the seven capabilities that separate a genuine FedRAMP platform from a generic GRC tool with a federal label on it. ## What capabilities matter most in a FedRAMP tool? The table below is the core evaluation rubric. Score each tool on these seven capabilities, weight them by your path (20x vs. Rev 5) and impact level, and you have a defensible shortlist without ever consulting a ranked listicle. | Capability | Why it matters | What good looks like | | --- | --- | --- | | Control mapping & SSP generation | The SSP and its control narratives are the backbone of a Rev 5 package; mapping is where teams bleed the most hours | Suggests control mappings with the signal that triggered them, drafts narratives in a strict template, and flags missing elements (e.g., "MFA described but re-auth frequency missing") | | Continuous evidence collection | Evidence as a pile of screenshots drifts the moment systems change; assessors want a regenerable pipeline | Pulls from cloud config, IAM, scanners, and CI/CD on a schedule; normalizes evidence into who/what/when/where objects with a change history | | POA&M management | POA&Ms rot when stale and political; remediation SLAs are strict (Critical 30 days, High 90, Moderate 180, Low 365) | Ingests findings from scanners and assessments, deduplicates, tracks aging and exceptions, and links each item to before/after remediation evidence | | OSCAL output | OSCAL is the machine-readable backbone of the digital package; structured data is what lets tools validate and diff your package | Emits valid OSCAL JSON/XML/YAML for SSP, SAP, SAR, and POA&M; passes schema and completeness checks; round-trips without manual repair | | KSI automation (20x) | FedRAMP 20x is built on KSIs that must be validated continuously and proven with machine-readable evidence | Maps signals to specific KSI validations with pass/fail criteria, runs on the 3-day/7-day cadence, and regenerates the evidence package on demand | | Continuous monitoring (ConMon) | Authorization is ongoing; monthly scans, inventory updates, and POA&M progress never stop | Detects drift inside the boundary, refreshes affected evidence and narratives automatically, and generates "what changed" summaries for monthly reporting | | Multi-cloud coverage | Real systems span AWS, Azure, and GCP plus identity and dev tooling; coverage gaps become findings | Connects to the major clouds, identity providers, scanners, and CI/CD through APIs rather than manual exports, with full-boundary coverage detection | > Source: [FedRAMP 20x Persistent Validation and Assessment — fedramp.gov](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) A tool does not need to be best-in-class at all seven. It needs to be strong at the capabilities that match your path. A 20x-native provider can live with thinner Rev 5 SSP tooling but cannot compromise on KSI automation; a Rev 5 program pursuing a sponsor cares more about SSP generation and control mapping than about a 3-day validation cadence it is not yet subject to. ## What capabilities matter most for FedRAMP 20x? For FedRAMP 20x, the capabilities that matter most are KSI automation, continuous evidence collection, and OSCAL output — because 20x fundamentally changes what counts as evidence. It does not want a control-by-control narrative backed by a folder of screenshots. It wants a machine-readable, human-readable package that addresses each KSI validation, carries source and timestamp metadata, and can be **regenerated on demand**. That single requirement is why a tool that only produces a quarterly PDF report cannot support a 20x program. The cadence requirement reinforces the point. For machine-based information resources, validation must run at least every 7 days at Low and at least every 3 days at Moderate; non-machine-based validations must complete at least once every 3 months ([FedRAMP 20x Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/)). No human team re-gathers evidence across an entire boundary every 72 hours. Only a pipeline does that, which makes automation an operating model rather than an audit-week sprint. There is one subtlety a good 20x tool must handle: a failure of the validation process is itself treated as a vulnerability and must be routed through Vulnerability Detection and Response. A tool that silently stops collecting is not passing — it is generating an open finding. Strong KSI automation therefore treats a broken pipeline as a work item with an owner, not a retry buried in a log. For a deeper walkthrough of building this, see how to [automate KSI evidence](/blog/20x/fedramp-20x-ksi-evidence-automation). A practical 20x filter: ask any vendor to show you a regenerated evidence package for a single KSI validation, with the source system, timestamp, expected state, observed state, and pass/fail result for each in-scope resource. If they can produce that on demand, the tool understands 20x. If they hand you a screenshot of a dashboard, it does not. ## How do you evaluate a FedRAMP compliance tool? You evaluate a FedRAMP compliance tool by running it against your real boundary on your real cloud accounts, not by reading a feature matrix. The features that demo well in a sandbox are often the ones that break against a messy production environment — undocumented external connections, inconsistent tagging, resources that fall outside coverage. A two-week proof of concept on your own data tells you more than any vendor deck. Use these questions during evaluation, in roughly this order: - **Does it connect to our actual systems through APIs?** Manual exports cannot be regenerated on demand and quietly miss new resources. Prefer tools that read from systems of record. - **Does it show its work?** When it maps a signal to a control or KSI, can it explain which signal triggered the mapping and what evidence is still missing? Reviewers reward traceability, not confidence. - **Does it detect drift tied to our boundary?** Adding a service inside the boundary should trigger an evidence refresh and update affected narratives, not just fire an alert. - **Does its OSCAL actually validate?** Ask for an exported OSCAL package and run it through schema and completeness checks. "OSCAL export" that fails validation is a checkbox, not a capability. - **Where does AI help, and where could it hurt?** AI is valuable for drafting narratives in strict templates, spotting gaps, and normalizing messy evidence. It is a liability when it invents implementation details or overstates coverage. A good tool keeps AI grounded in evidence inside your boundary. - **Does it use current 2026 terminology?** Tools and content that still say "FedRAMP Validated" or reference numbered levels instead of Certification Classes A–D are behind, and that lag often shows up in their data models too. One more evaluation lens that teams forget: total cost of ownership across the authorization lifecycle, not the sticker price. A cheaper tool that requires a quarter of an engineer's time to keep running is more expensive than a pricier one that runs itself. We break the full economics down in our guide to [FedRAMP cost](/blog/20x/fedramp-cost-2026). ## How does Boundera approach these capabilities? Boundera is an AI copilot for FedRAMP built around the exact capability set above, which makes it a useful concrete example of what "good" looks like in practice. It connects to the authoritative sources a FedRAMP program depends on — cloud configuration, identity providers, and vulnerability scanners such as Qualys and Tenable — and continuously collects current state rather than asking teams to re-gather it before each review. The first-hand lesson from real engagements is where Boundera focuses. The work that consumes the most time is not running scanners; it is **mapping each signal to the right control or KSI validation with defensible pass/fail criteria and keeping that mapping current as the boundary changes**. Boundera uses AI control evaluation to propose those mappings — including the SP 800-53 controls each KSI rolls up — drafts SSP narratives in a strict template, and flags resources that fall out of coverage so the consolidated information-resource list stays accurate. The output is a structured evidence package that is machine-readable and human-readable, carries source and timestamp metadata, and regenerates on demand. The honest framing is that automation does not erase every task. Cybersecurity education, recovery testing, and incident exercises still need a real cadence and real human records. What automation does is collapse the machine-based majority of the work into a continuous, low-effort flow, so scarce engineering and compliance time goes to judgment-heavy validations and to fixing genuine findings. If your package already exists in document form, the practical first step is structuring it — see how to [convert your SSP to OSCAL](/blog/20x/ssp-to-oscal-guide) before layering automation on top. ## Build vs. buy: should you build your own FedRAMP tooling? Build vs. buy comes down to opportunity cost, and for most CSPs buying wins — not because building is impossible, but because the maintenance never ends. A homegrown evidence pipeline is straightforward to prototype: pull cloud config, run some checks, write the results to a file. The hard part is everything after the prototype — keeping connectors current as cloud APIs change, handling full-boundary coverage detection, treating pipeline failures as vulnerabilities, emitting valid OSCAL, and meeting a 3-day cadence without an engineer babysitting it. Building can make sense when you have unusual architecture that no tool models well, a strong platform-engineering team with spare cycles, or a strategic reason to own the pipeline as intellectual property. Buying makes sense when your engineers' time is better spent on the product, when you want lifecycle coverage out of the box, and when you need to be assessment-ready on a predictable timeline rather than whenever the internal tool gets finished. A common middle path works well: buy the platform for evidence collection, mapping, SSP generation, and OSCAL output, and build only the thin, system-specific connectors your environment needs that no vendor ships. That keeps your engineering investment focused on what is genuinely unique to you, while the undifferentiated heavy lifting — the cadence, the coverage, the OSCAL — comes from a tool that maintains it for you. ## Frequently asked questions ### What are FedRAMP compliance tools? FedRAMP compliance tools are software platforms that help cloud service providers achieve and maintain FedRAMP authorization by automating control mapping, SSP generation, evidence collection, POA&M management, OSCAL output, and continuous monitoring. In 2026 the strongest tools also automate Key Security Indicator (KSI) validation for FedRAMP 20x, producing machine-readable evidence that can be regenerated on demand. The goal is to turn the authorization package from a static set of documents into living, continuously validated data. ### What is the best FedRAMP compliance tool in 2026? There is no single best tool for every provider — the right choice depends on your path and impact level. Evaluate against seven capabilities (control mapping/SSP generation, continuous evidence collection, POA&M management, OSCAL output, KSI automation, ConMon, and multi-cloud coverage) and weight them by whether you are pursuing FedRAMP 20x or Rev 5. Boundera is one strong option built specifically for this capability set, with AI control evaluation, SSP generation, and continuous KSI evidence. ### Do FedRAMP tools support FedRAMP 20x and KSIs? Not all of them do, and this is a key differentiator in 2026. FedRAMP 20x requires evidence that is machine-readable, regenerable on demand, and validated on a strict cadence (at least every 7 days at Low and 3 days at Moderate for machine-based resources). A tool built for Rev 5 documentation alone cannot satisfy these requirements, so confirm explicitly that any tool maps signals to specific KSI validations and produces a regenerable evidence package. ### What is OSCAL and why do FedRAMP tools need it? OSCAL (Open Security Controls Assessment Language) is a NIST-led set of formats (JSON, XML, YAML) that represents controls, system implementations, assessment results, and remediation plans as structured data. FedRAMP tools need it because the digital authorization package is moving to machine-readable submissions, and structured data is what lets tools validate, diff, and continuously update your package instead of rewriting documents. Ask any vendor for an OSCAL export and run it through schema validation before you trust the claim. ### Should I build my own FedRAMP automation or buy a tool? For most CSPs, buying wins on opportunity cost. Prototyping an evidence pipeline is easy; maintaining one that keeps connectors current, detects coverage gaps, emits valid OSCAL, and meets a 3-day cadence without constant engineering attention is not. A common middle path is to buy the platform and build only the thin, system-specific connectors your environment uniquely needs. ### What 2026 FedRAMP terminology should I know? In 2026 there is a single **FedRAMP Certified** label rather than separate validation tiers, and certification is organized into **Classes A, B, C, and D** that describe the depth and ongoing information burden of a certification profile rather than numbered impact levels. Cloud-native 20x providers generally focus on Classes A, B, and C. Tools or content still using "FedRAMP Validated" or numbered levels are out of date. ### How much should FedRAMP compliance tooling cost? Tooling cost varies widely by scope and is a small fraction of total FedRAMP program cost, which is dominated by 3PAO assessment, engineering effort, and continuous monitoring. Evaluate total cost of ownership across the lifecycle rather than sticker price — a tool that runs itself can be cheaper than a free or cheap one that consumes ongoing engineering time. See our full breakdown in the [FedRAMP cost](/blog/20x/fedramp-cost-2026) guide. ### Can AI tools be trusted for FedRAMP compliance? AI is valuable for FedRAMP when it behaves like a disciplined assistant — drafting narratives in strict templates, spotting missing control elements, normalizing messy evidence, and proposing mappings with their reasoning shown. It becomes a liability when it invents implementation details or overstates coverage, because any claim that cannot be backed by evidence inside your boundary is a finding waiting to happen. The right pattern is AI grounded in real evidence, with humans owning judgment and final sign-off. ## Sources - [FedRAMP 20x Persistent Validation and Assessment — fedramp.gov](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [FedRAMP 20x Key Security Indicators — fedramp.gov](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [NIST OSCAL documentation — pages.nist.gov](https://pages.nist.gov/OSCAL/) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP Continuous Monitoring Checklist: Monthly and Annual - URL: https://boundera.io/blog/rev5/fedramp-conmon-checklist - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:35Z - Reading time: 9 minutes - Main question: What is the FedRAMP continuous monitoring checklist for monthly and annual deliverables? - TL;DR: FedRAMP ConMon runs on a fixed cadence: every month you submit vulnerability scans of operating systems, web applications, and databases, an updated POA&M, and a current inventory to your secure repository; every year an independent assessor reassesses a subset of controls; and as needed you file significant change requests and deviation requests for your agency AO to approve. - Excerpt: A FedRAMP ConMon checklist: monthly vulnerability scans, POA&M, and inventory; the annual assessment; and as-needed significant change and deviation requests. # FedRAMP Continuous Monitoring Checklist: Monthly and Annual FedRAMP continuous monitoring (ConMon) runs on a fixed cadence: **every month** you submit updated vulnerability scans of your operating systems, web applications, and databases, an updated Plan of Action and Milestones (POA&M), and a current asset inventory to your secure repository; **every year** an independent assessor reassesses a subset of your controls; and **as needed** you file significant change requests and deviation requests for your agency Authorizing Official (AO) to approve. Miss the monthly rhythm and your authorization can be put at risk. This checklist lays out what is due, how often, and who owns each item so the cadence never becomes a fire drill. **Key takeaways** - The three core monthly deliverables are **vulnerability scans (OS, web app, database), the POA&M, and the inventory** — uploaded to your secure repository for agency AO review. - Per FedRAMP, ConMon deliverables are provided on **four cadences: monthly, annually, every three years, and as-needed**. - Vulnerability scans must cover **operating systems, web applications, and databases at least monthly**. - Remediation timelines are SLA-driven: **Critical 30 days, High 90 days, Moderate 180 days, Low 365 days** from detection. - The **annual assessment** is a fresh, independent assessment of a control subset — not a paperwork refresh — and is required every year. - **Significant changes** require a security impact analysis up front and AO approval before (or, by agreement, around) the change; **deviation requests** for false positives, risk adjustments, and operational requirements also need AO sign-off. - This is a companion to our deeper narrative on [continuous monitoring after ATO](/blog/rev5/fedramp-continuous-monitoring-after-ato) — use that for the "why," and this checklist for the "what and when." ## What is FedRAMP continuous monitoring? FedRAMP continuous monitoring is the ongoing program of scanning, reporting, assessment, and change management that keeps an authorized cloud service offering (CSO) trustworthy after it goes live. FedRAMP bases ConMon on NIST SP 800-137, and the program defines three goals: **operational visibility, managed change control, and incident response**. The CSP produces a recurring stream of deliverables that agency AOs review to confirm the system's risk posture is still acceptable. Two points matter. First, ConMon is not optional or back-loaded; it begins the moment you are authorized and never ends while you hold an authorization. Second, under the 2026 terminology changes (NTC-0004), the program now uses a single **FedRAMP Certified** label and four **Certification Classes (A, B, C, D)** in place of the old Low / Moderate / High level names. The ConMon obligations below apply across baselines; the class labels describe the depth of your assessment package, not a change to the monitoring cadence itself. ## What are the monthly ConMon deliverables? Every month, you upload a refreshed package to your secure repository so agency AOs can review your current risk posture. The three load-bearing items are vulnerability scans, the POA&M, and the inventory. - **Vulnerability scans** must cover your **operating systems, web applications, and databases**, run at least monthly. Raw scan files are provided when required by your agreements with agency customers, along with summary reports. - **POA&M** is your living record of every known weakness — driven by NIST control **CA-5** — with the risk rating, owner, remediation plan, and milestone dates for each open finding. It must show active progress month over month. - **Inventory** is required by control **CM-8** at least monthly or whenever it changes, so the boundary the AO is reviewing matches the system actually running. Where do these go? CSPs at LI-SaaS, Low, or Moderate (Class B/C) post deliverables to the FedRAMP secure repository on USDA Connect.gov; CSPs at High (Class D) use their own secure repository. A monthly ConMon report and review meeting wrap these artifacts together so the agency team can ask questions and approve any pending requests. > Source: [FedRAMP Continuous Monitoring Overview — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/overview/) ## The FedRAMP ConMon checklist (monthly, annual, as-needed) This table is the checklist. Cadence reflects FedRAMP's four reporting frequencies; the "owner / output" column names who typically drives the task and what lands in the repository. | ConMon task | Cadence | Owner / output | | --- | --- | --- | | Vulnerability scans — OS, web applications, and databases | Monthly | CSP security/ops → raw scan files + summary | | Update POA&M (CA-5) with new/closed findings and milestones | Monthly | ISSO/compliance lead → updated POA&M | | Update system inventory (CM-8) | Monthly (or on change) | CSP ops → current asset inventory | | Monthly ConMon report + AO review meeting | Monthly | ISSO → executive summary; agency AO reviews | | Remediate findings within SLA (Crit 30 / High 90 / Mod 180 / Low 365 days) | Continuous, tracked monthly | Remediation owners → closed POA&M items + evidence | | Deviation requests (false positive, risk adjustment, operational requirement) | As needed | CSP → request; agency AO approves | | Significant change request + security impact analysis | As needed | CSP → SCR; AO approves; assessor may re-test | | Incident reporting per agreed timelines | As needed (per incident) | CSP → notification to AO/CISA | | Annual security assessment of a control subset | Annually | Independent assessor (3PAO) → annual SAR | | Update SSP and appendices; test IRP and Contingency Plan | Annually | CSP → updated SSP, test results | | Full reassessment / re-authorization activities | Every three years | CSP + assessor → updated package | > Source: [FedRAMP Continuous Monitoring Strategy Guide — fedramp.gov (PDF)](https://www.fedramp.gov/assets/resources/documents/CSP_Continuous_Monitoring_Strategy_Guide.pdf) ## What is required annually in FedRAMP ConMon? Each year, an independent assessor performs a fresh assessment of a selected subset of your controls — a real evaluation, not a documentation refresh. Alongside it you keep your authorization package current: update the System Security Plan and its appendices to reflect the system as it actually runs, and **test your Incident Response Plan and Contingency Plan** so those controls are demonstrably exercised, not just written down. The annual assessment produces an updated Security Assessment Report (SAR), and every new finding flows into your POA&M under the same SLA clock as any monthly finding. Treat it as the moment your year of monthly hygiene gets graded: if your scans, POA&M, and inventory have been accurate all year, the annual assessment confirms what the AO already knows; if you have let the cadence slip, this is where that debt comes due. A third cadence sits above the annual one: FedRAMP also defines deliverables on a **three-year** cycle, where broader reassessment and re-authorization activity lives. Budget for it — the recurring cost of these assessments is a frequent surprise, which we break down in the [hidden costs of FedRAMP](/blog/20x/fedramp-hidden-costs). ## What triggers a significant change request? A significant change is any change to your authorized system that could materially affect its security posture — adding a new external service, changing your authorization boundary, swapping a core component, or altering how data flows. Before making such a change, FedRAMP requires a **security impact analysis**, and depending on the change type, you route it through the significant change process for AO review and approval. Material changes may require the assessor to test affected controls out of cycle before the change is fully accepted. The discipline is front-loading. The security impact analysis is what separates a routine configuration update (handle it under normal change control) from a significant change (file the request). Skipping that analysis, or implementing a boundary-altering change and disclosing it later, is one of the faster ways to put an authorization in jeopardy. Significant changes are also a standing agenda item at the monthly ConMon meeting. Distinct from significant changes are **deviation requests**, filed when a scan finding does not warrant straight remediation: a **false positive** (evidence it is not a real vulnerability), a **risk adjustment** (real but mitigated to lower risk), or an **operational requirement** (cannot be remediated without breaking required functionality, so you document compensating controls). All three require agency AO approval before the item is marked as such in the POA&M. ## How does automation keep the monthly cadence from becoming a fire drill? The hard part of ConMon is not any single deliverable — it is producing all of them accurately every month, forever, while still shipping product. The failure mode is predictable: scans run late, the POA&M drifts out of sync with the latest scan results, the inventory stops matching reality, and the team scrambles in the final days before the upload. That scramble is where errors and missed SLAs are born. This is the case for treating ConMon as a continuous pipeline rather than a monthly project. At Boundera, our AI copilot keeps the three core artifacts in lockstep: scan results feed directly into POA&M entries with the correct control mapping and SLA clock, the inventory reconciles against what is actually deployed in the boundary, and the monthly package assembles from a system of record that is always current. The goal is not to replace your ISSO's judgment on deviation or significant change requests; it is to remove the manual reconciliation that turns a routine upload into a fire drill, so human review happens on clean, complete data. The same automation-first posture underpins the [KSI validation cadence](/blog/20x/fedramp-20x-ksi-validation) on the FedRAMP 20x path, where continuous evidence is the entire model. ## Frequently asked questions ### What are the monthly FedRAMP ConMon deliverables? The core monthly deliverables are **vulnerability scans of your operating systems, web applications, and databases; an updated POA&M; and an updated inventory**, uploaded to your secure repository with a monthly ConMon report. Raw scan files are provided when your agency agreements require them. ### How often must FedRAMP vulnerability scans run? At least **monthly**, covering operating systems, web applications, and databases across the authorization boundary. Scans missing any of these three categories, or missing components inside the boundary, are a common ConMon finding. New significant changes can trigger additional out-of-cycle scanning. ### What are the FedRAMP POA&M remediation SLAs? Findings must be remediated within FedRAMP's standard timelines from detection: **Critical in 30 days, High in 90 days, Moderate in 180 days, and Low in 365 days**. Missed milestones must be tracked in the POA&M and can become findings in themselves, so set realistic completion dates. ### What is the FedRAMP annual assessment? It is an independent reassessment of a **subset of your controls** performed every year by an assessor (typically a 3PAO), producing an updated SAR. You also refresh your SSP and appendices and test your Incident Response and Contingency Plans annually. New findings flow into the POA&M under standard SLAs. ### When do I need a significant change request? When a planned change could materially affect your system's security posture — boundary changes, new external connections, or replacing core components. Perform a **security impact analysis** first, then route the change for AO review and approval; the assessor may need to test affected controls out of cycle. ### What is a FedRAMP deviation request? A deviation request asks the AO to accept a scan finding without standard remediation. The three types are **false positive** (not a real vulnerability), **risk adjustment** (real but lower-risk due to mitigations), and **operational requirement** (cannot be fixed without breaking functionality). All require AO approval before being recorded as such in the POA&M. ### Where do CSPs submit ConMon deliverables? CSPs categorized at LI-SaaS, Low, or Moderate (Certification Classes B and C) post deliverables to the FedRAMP secure repository on **USDA Connect.gov**. CSPs at High (Class D) use **their own secure repository**. Either way, the agency AO reviews the monthly package there. ### Does FedRAMP 20x change the ConMon cadence? The 2026 terminology shift to a single **FedRAMP Certified** label and Certification Classes A–D changes how baselines are named, not the monthly-scan, POA&M, and inventory rhythm. FedRAMP 20x leans further into continuous, automated evidence, but the underlying expectation — keep risk posture visible and current — is the same. ## Sources - [FedRAMP Continuous Monitoring Overview — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/overview/) - [FedRAMP Continuous Monitoring Strategy Guide (PDF) — fedramp.gov](https://www.fedramp.gov/assets/resources/documents/CSP_Continuous_Monitoring_Strategy_Guide.pdf) - [Vulnerability Scanning — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/vulnerability-scanning/) - [Annual Assessment — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/annual-assessment/) - [Significant Changes — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/significant-changes/) - [NTC-0004: FedRAMP Certification labels and Classes — fedramp.gov](https://www.fedramp.gov/notices/0004/) - [NIST SP 800-137, Information Security Continuous Monitoring — nist.gov](https://csrc.nist.gov/pubs/sp/800/137/final) --- _Last updated: June 2026. Written by the Boundera team. Boundera is an AI copilot for FedRAMP that keeps your scans, inventory, and POA&M in lockstep so the monthly ConMon cadence stays routine instead of a fire drill._ ### FedRAMP for AI and LLM Platforms: What's Different - URL: https://boundera.io/blog/20x/fedramp-for-ai-platforms - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:34Z - Reading time: 9 minutes - Main question: Does FedRAMP apply to AI and LLM platforms? - TL;DR: FedRAMP applies to AI and LLM platforms like any cloud service: if a federal agency processes its data in your AI offering, it needs to be FedRAMP Certified. What's different is scope - the model, training/fine-tuning data, third-party model APIs, and prompt/output logging all enter the boundary. As of August 18, 2025, FedRAMP also prioritizes qualifying conversational AI services for a faster 20x authorization. - Excerpt: How FedRAMP applies to AI and LLM cloud services in 2026: the AI prioritization fast lane, model-boundary scoping, training data, and prompt/output logging. # FedRAMP for AI and LLM Platforms: What's Different FedRAMP applies to AI and LLM platforms the same way it applies to any cloud service: if a federal agency uses your AI offering to process, store, or transmit federal information, it needs a FedRAMP authorization. What changes for AI is not the framework but the *scope* — your authorization boundary now has to account for models, training and fine-tuning data, third-party model APIs, and the prompts and outputs flowing through the system. As of August 2025, FedRAMP also formally [prioritizes certain conversational AI services](https://www.fedramp.gov/ai/) for faster authorization through the FedRAMP 20x path. **Key takeaways** - FedRAMP applies to AI/LLM cloud services like any other Cloud Service Offering; there is no separate "AI authorization." - FedRAMP began prioritizing qualifying conversational AI services on **August 18, 2025**, routing them through a FedRAMP 20x process modeled on the Phase One pilot. - The hard part of AI authorization is the **boundary**: the model, its weights, training/fine-tuning data, third-party model APIs, and prompt/output logging all have to be scoped, controlled, and documented. - FedRAMP's current label is **FedRAMP Certified**, covering both Rev 5 and 20x; certification depth is described by **Classes A, B, C, and D** rather than numbered levels. - NIST's [AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) and its Generative AI Profile are the reference points for the AI-specific risks FedRAMP evidence should address. ## Does FedRAMP apply to AI platforms? Yes. FedRAMP is the U.S. government's standardized program for authorizing the cloud services that agencies use, and an AI or LLM platform delivered as a hosted service is a cloud service. If an agency will put federal information into your chatbot, retrieval system, agent, or model API, that offering falls within FedRAMP's scope and needs to be **FedRAMP Certified** before broad agency use. There is no separate "AI track" that replaces the core program. AI services are still categorized under FIPS 199, still implement a NIST SP 800-53 Rev 5 baseline (for the Rev 5 path) or the FedRAMP 20x Key Security Indicators (for the 20x path), and still go through the same authorization and continuous-monitoring lifecycle. What FedRAMP added in 2025 is *prioritization* — a way to move qualifying AI services through faster — not a different rulebook. Under the 2026 terminology, you will see a single authorization label, **FedRAMP Certified**, that spans both Rev 5 and 20x. The older marketing-style phrases are gone, and certification depth is expressed through Classes (A=new pilot entry, B=light-use and Low, C=Moderate, D=High) rather than numbered tiers. For most AI vendors entering the federal market, the practical target is Class B or Class C depending on the data agencies will entrust to the system. See our explainer on [FedRAMP impact levels](/blog/rev5/fedramp-low-moderate-high-impact-levels) for how the underlying categorization works. ## What's different about authorizing an AI/LLM service? The framework is the same; the surface area is bigger. A conventional SaaS application has a fairly stable set of components — application servers, databases, identity, logging. An AI platform adds several moving parts that change confidentiality, integrity, and availability analysis and create new evidence obligations. | Consideration | Standard SaaS | AI / LLM platform | | --- | --- | --- | | Boundary components | App, data stores, identity, logging | All of that **plus** the model/weights, inference layer, vector stores, and any model-serving infrastructure | | Data inventory | Customer records, operational data | Customer data **plus** prompts, outputs, embeddings, and any training/fine-tuning datasets | | External dependencies | Auth, payment, email APIs | Third-party **model APIs** that may sit outside your boundary and must be authorized or compensated for | | Data separation | Tenant isolation | Tenant isolation **plus** guarantees that customer data does not improve a shared model without authorization | | Logging (AU family) | Access and system logs | Access logs **plus** prompt/response logging, which is itself sensitive and must be protected | | Integrity risks (SI family) | Code, config, data integrity | Model behavior, prompt injection, data-poisoning, and output reliability | | Supply chain (SR family) | Software dependencies | Software **plus** model provenance, base-model lineage, and dataset sourcing | The recurring theme is that data which was incidental in a normal SaaS — the contents of a request — becomes core, regulated content in an AI system. A prompt can contain CUI. An output can leak training data. Embeddings can be reversible. Each of these has to be located inside the boundary, protected, logged, and explained in your authorization package. NIST's [Generative AI Profile (NIST AI 600-1)](https://www.nist.gov/itl/ai-risk-management-framework) catalogs the risks specific to generative systems — confabulation, data leakage, harmful outputs, and provenance gaps among them. It is voluntary guidance, not a FedRAMP requirement, but it is the most authoritative map of *what* an AI authorization should demonstrate it has under control, and it pairs naturally with the SI, SR, and PT (privacy) control families. ## How does FedRAMP's AI prioritization work? FedRAMP began prioritizing certain AI cloud services on **August 18, 2025**, following recommendations from the FedRAMP Board and the CIO Council and as contemplated by the FedRAMP Authorization Act. The prioritization targets **conversational AI engines designed for routine, repeated use by federal workers** — the assistant-style products agencies want in the hands of their workforce. Per the official [FedRAMP AI Prioritization page](https://www.fedramp.gov/ai/), a service must meet **all** of the following to be prioritized: - Offer enterprise-grade features including single sign-on, SCIM provisioning, role-based access control, and real-time analytics. - Guarantee data separation and protection — any model information learned from training on customer data must not leave the customer environment without customer authorization. - Establish demand from **at least five CFO Act agencies**, or be specifically recommended by the CIO Council. - Be available for government purchase via the GSA Multiple Award Schedule. - Be able to meet the requirements for a **FedRAMP 20x** authorization within **two months** of acceptance for prioritization. Prioritized providers follow a process modeled on the FedRAMP 20x Phase One pilot: they contact the FedRAMP Director directly, meet the Phase One initial submission requirements, and receive additional pre- and post-authorization support. Submissions are accepted outside the standard window, with no fixed deadline. As of the page's publication, ChatGPT Enterprise and API Platform (OpenAI), Gemini for Government (Google), and Perplexity Enterprise Pro for Government were all listed as on track for **FedRAMP 20x Low** authorization, with additional services added as they qualify. Two things matter here for vendors. First, prioritization is a fast lane, not a lowered bar — the security expectations of 20x still apply. Second, the data-separation criterion is effectively a hard control: if customer prompts or fine-tuning can silently improve a shared model, you do not qualify. That single requirement reshapes how many AI products are architected for government. ## How do you scope an AI system boundary? Start from the same principle as any FedRAMP boundary — everything that processes, stores, or transmits federal information is in scope — and then walk the AI-specific data path end to end. For an LLM service the boundary almost always has to include: - **The inference/serving layer** and the model weights it loads, wherever they run. - **Prompt and output handling**, including any queueing, caching, or logging of requests and responses. - **Retrieval and memory stores** — vector databases, embeddings, and any conversation history — because these hold derived copies of customer data. - **Fine-tuning and training pipelines** if customer data ever reaches them, along with the datasets themselves. - **Third-party model APIs.** If your platform calls an external foundation-model API, that dependency is a boundary decision. It must either be FedRAMP-authorized in its own right or treated as an external service with documented compensating controls and a clear data-handling agreement. Sending federal prompts to an unauthorized external model is a classic scope failure. The cleanest AI boundaries keep inference, prompt/output logging, and any tuning data inside a controlled, monitored environment, and they document explicitly where customer data is *not* used — for example, that prompts never train a shared base model. That negative statement is as important to your authorization package as any positive control, because it is exactly what the prioritization criteria and agency reviewers will look for. For the fundamentals of drawing a boundary, our guide to [FedRAMP impact levels](/blog/rev5/fedramp-low-moderate-high-impact-levels) covers the categorization step that determines how strict that boundary has to be. ## Why automated, continuous evidence fits AI systems especially well AI platforms change fast. Models get swapped, retrained, and re-tuned; prompts and retrieval sources evolve; new endpoints ship weekly. A point-in-time authorization that snapshots the system once a year is a poor match for a service whose security-relevant behavior moves that quickly — which is precisely why FedRAMP 20x is built around continuous, machine-readable validation rather than static narratives. This is the Boundera angle, and it is a structural fit rather than a sales pitch: when evidence is collected continuously and automatically from the live environment, the authorization stays current as the model and pipeline change. Configuration of the inference layer, encryption of prompt/output stores, access controls on training data, and the data-separation guarantees behind the prioritization criteria can all be expressed as Key Security Indicators and re-validated on a cadence rather than reconstructed by hand at assessment time. For AI vendors targeting the 20x path, building that pipeline early is the difference between sustainable compliance and a scramble every cycle — see our walkthrough on how to [automate KSI evidence](/blog/20x/fedramp-20x-ksi-evidence-automation). ## Frequently asked questions ### Is there a separate FedRAMP authorization just for AI? No. AI and LLM services use the same FedRAMP program, the same FIPS 199 categorization, and the same Rev 5 or 20x requirements as any other cloud service. What exists is a *prioritization* mechanism, effective August 18, 2025, that routes qualifying conversational AI services through a faster 20x process — not a separate or lighter authorization standard. ### What does "FedRAMP Certified" mean for an AI product in 2026? FedRAMP Certified is the single authorization label that now covers both the Rev 5 and 20x paths. An AI product that is FedRAMP Certified has completed authorization at a defined certification Class (A, B, C, or D) reflecting the depth and expected use of the service. You should not see legacy phrases like "validated" or numbered "levels"; FedRAMP rejected numbered levels in favor of Classes. ### Do I need FedRAMP if my AI service only calls a third-party model API? If federal agencies use your service with federal information, yes — and the third-party model API becomes a boundary decision. That external model must either be FedRAMP-authorized itself or treated as an external dependency with documented data-handling controls. You cannot send federal prompts to an unauthorized external model and consider it out of scope. ### How does the data-separation requirement affect model training? It is effectively a hard control for prioritized AI services. FedRAMP's prioritization criteria require that any model information learned from training on customer data must not leave the customer environment without customer authorization. In practice this means customer prompts and fine-tuning data cannot silently improve a shared base model, and your architecture and documentation must prove it. ### Do prompts and outputs need to be logged for FedRAMP? Audit and accountability (the AU control family) still apply, and for AI systems prompts and outputs are often the most security-relevant records. The catch is that prompt/output logs frequently contain sensitive data themselves, so they must be protected, access-controlled, and retained according to the same rules as the data they capture. Logging design is part of your boundary and SSP, not an afterthought. ### How does the NIST AI Risk Management Framework relate to FedRAMP? The NIST AI RMF and its Generative AI Profile (NIST AI 600-1) are voluntary guidance that catalog AI-specific risks like data leakage, confabulation, and provenance gaps. FedRAMP does not require the AI RMF, but it is the authoritative reference for *what* AI-specific risks your authorization evidence should address, and it maps cleanly onto the SI, SR, and PT control families. ### Which certification Class should an AI vendor target? It depends on the data agencies will put into the system and how broadly they will rely on it. Class B suits lighter-use, Low-impact services; Class C is the common target for enterprise platforms handling Moderate-impact data. The prioritized conversational AI services listed by FedRAMP were tracking toward FedRAMP 20x Low. Use a FIPS 199 categorization to decide rather than defaulting to the lowest tier. ### How much does authorizing an AI platform cost? There is no separate AI price; cost tracks the chosen path, impact level, and certification Class like any cloud service, with the 20x path generally lighter than legacy Rev 5. The added AI scope — model serving, training-data controls, prompt/output logging — can increase effort within a given level. See our breakdown of [FedRAMP cost](/blog/20x/fedramp-cost-2026) for current ranges. ## Sources - [FedRAMP AI Prioritization — fedramp.gov/ai](https://www.fedramp.gov/ai/) - [FedRAMP 20x Overview — fedramp.gov/20x](https://www.fedramp.gov/20x/) - [NIST AI Risk Management Framework — nist.gov](https://www.nist.gov/itl/ai-risk-management-framework) - [NIST AI RMF: Generative AI Profile (NIST AI 600-1)](https://doi.org/10.6028/NIST.AI.600-1) - [NIST Computer Security Resource Center — csrc.nist.gov](https://csrc.nist.gov/) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP vs CMMC: Which Federal Security Program Do You Need? - URL: https://boundera.io/blog/rev5/fedramp-vs-cmmc - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:33Z - Reading time: 9 minutes - Main question: What is the difference between FedRAMP and CMMC, and which do I need? - TL;DR: FedRAMP authorizes a cloud service so federal agencies can use it (NIST 800-53, assessed by a 3PAO). CMMC certifies that a DoD contractor protects FCI/CUI (NIST 800-171, Levels 1-3, assessed by self-assessment, a C3PAO, or DIBCAC). You need FedRAMP to sell cloud to agencies and CMMC to hold DoD contracts touching FCI/CUI; some companies need both. - Excerpt: FedRAMP authorizes cloud services for federal agencies; CMMC certifies defense contractors handling FCI/CUI. Here's which one you need, and when you need both. # FedRAMP vs CMMC: Which Federal Security Program Do You Need? FedRAMP and CMMC are not competing standards or alternative versions of the same thing. **FedRAMP authorizes a cloud service so federal agencies can buy and use it; CMMC certifies that a defense contractor protects the sensitive information it handles under a DoD contract.** If you sell a cloud product to civilian or defense agencies, you need FedRAMP. If you are a defense contractor or supplier touching Federal Contract Information (FCI) or Controlled Unclassified Information (CUI), you need CMMC. Some companies need both, and one can directly support the other. **Key takeaways** - **FedRAMP** is a cloud-service authorization built on NIST SP 800-53, assessed by a 3PAO, and aimed at any federal agency. In 2026 the program uses a single **"FedRAMP Certified"** label with Certification Classes A, B, C, and D. - **CMMC** is a DoD contractor certification built on NIST SP 800-171 (and SP 800-172 at the top tier), with **Levels 1, 2, and 3**, assessed by self-assessment, a C3PAO, or DIBCAC depending on level. - The CMMC program rule (32 CFR Part 170) is final, and the contractual DFARS clause **252.204-7021 became effective November 10, 2025**, rolling CMMC requirements into DoD contracts over a phased, multi-year schedule. - If a cloud service stores, processes, or transmits CUI for a CMMC Level 2 contractor, that cloud must meet **FedRAMP Moderate (or FedRAMP Moderate equivalency)** under DFARS 252.204-7012. - FedRAMP Moderate equivalency is **not** the same as a FedRAMP Moderate authorization, even though both reference the same Moderate baseline. ## What's the difference between FedRAMP and CMMC? The cleanest way to tell them apart is to ask *what is being certified*. FedRAMP certifies a **cloud service offering**. CMMC certifies a **company's information systems** that handle government data under contract. | | **FedRAMP** | **CMMC** | | --- | --- | --- | | **What it certifies** | A cloud service offering (SaaS, PaaS, IaaS) | A defense contractor's systems handling FCI/CUI | | **Who requires it** | U.S. federal agencies buying cloud services | The Department of Defense, flowed down through contracts | | **Data type** | Federal agency data hosted in the cloud | Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) | | **Control framework** | NIST SP 800-53 baselines | NIST SP 800-171 (Levels 1–2); NIST SP 800-172 adds requirements at Level 3 | | **Who assesses** | A FedRAMP-recognized 3PAO | Self-assessment, a C3PAO (Level 2), or government DIBCAC (Level 3) | | **Tiers** | One "FedRAMP Certified" label, Certification Classes A/B/C/D | Levels 1, 2, and 3 | | **Output** | A FedRAMP authorization package and listing | A CMMC status recorded and affirmed in SPRS | | **Ongoing duty** | Continuous monitoring (ConMon) | Annual affirmation; reassessment on the program cycle | > Source: [FedRAMP.gov](https://www.fedramp.gov/) and [DoD CIO — CMMC](https://dodcio.defense.gov/CMMC/) The frameworks even draw from the same family tree but at different points. FedRAMP uses **NIST SP 800-53**, the catalog of controls for federal information systems. CMMC uses **NIST SP 800-171**, the standard for protecting CUI in *nonfederal* systems, which itself is derived from 800-53. That shared lineage is why the two programs feel similar and why evidence collected for one can shorten the path to the other. ## Who needs FedRAMP, and who needs CMMC? You need **FedRAMP** if you operate a cloud service and want a federal agency, civilian or defense, to use it. Agencies are generally prohibited from using cloud services that lack a FedRAMP authorization, so for a SaaS company "selling to the federal government" almost always means "getting FedRAMP Certified." You need **CMMC** if you are in the **defense industrial base**: a prime contractor, subcontractor, or supplier whose contract involves FCI or CUI. CMMC is not something you pursue speculatively. It is driven by contract language. When a solicitation includes the DFARS 252.204-7021 clause, it specifies the **CMMC level** the contractor must hold before award. The level you need depends on the data you touch: - **CMMC Level 1** applies to contractors handling only **FCI**. It covers the 15 basic safeguarding requirements from FAR 52.204-21 and is met by an **annual self-assessment**. - **CMMC Level 2** applies to contractors handling **CUI**. It maps to the **110 security requirements of NIST SP 800-171 Revision 2**. Depending on the contract, Level 2 is met by either a self-assessment or a third-party assessment performed by a **C3PAO** (a Certified Third-Party Assessment Organization). - **CMMC Level 3** applies to a smaller set of programs with the highest-priority CUI. It requires a **Final Level 2 (C3PAO)** status first, then a government assessment by **DIBCAC** against **24 additional requirements drawn from NIST SP 800-172**. > Source: [Federal Register — CMMC Program final rule (32 CFR Part 170)](https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program) A useful gut check: FedRAMP is keyed to **who hosts the data** (a cloud provider), while CMMC is keyed to **who holds the contract** (a defense supplier). A defense manufacturer with no cloud product of its own still needs CMMC. A SaaS vendor with no DoD contract still needs FedRAMP to sell to agencies. The two questions are independent — which is exactly why some companies answer "yes" to both. ## Is FedRAMP Moderate equivalent to CMMC? No. FedRAMP and CMMC certify different things, so neither one substitutes for the other. But there is a specific, frequently confused intersection: **FedRAMP Moderate equivalency** for cloud providers that handle CUI. Under **DFARS 252.204-7012**, when a contractor uses an external cloud service to store, process, or transmit covered defense information (a category of CUI), that cloud service must meet the **FedRAMP Moderate baseline or be "FedRAMP Moderate equivalent."** Because CMMC Level 2 is built on the same DFARS 7012 obligations, this requirement flows into CMMC: a Level 2 contractor's cloud providers must clear the FedRAMP Moderate bar. Two points trip people up: 1. **Equivalency is a pathway, not an authorization.** DoD's equivalency guidance lets a cloud service demonstrate it meets the FedRAMP Moderate security requirements without holding a formal FedRAMP authorization. Meeting equivalency does **not** make a cloud service "FedRAMP Certified," and it does not place it on the FedRAMP marketplace. 2. **The requirement lands on the cloud provider, not on the prime alone.** If your SaaS product handles CUI inside a defense contractor's workflow, *you* are the one who has to satisfy FedRAMP Moderate or equivalency, even though *they* hold the CMMC obligation. > Source: [DoD CIO — FedRAMP Equivalency for Cloud Service Providers](https://dodcio.defense.gov/Portals/0/Documents/Library/FEDRAMP-EquivalencyCloudServiceProviders.pdf) So "Is FedRAMP Moderate equivalent to CMMC?" mixes two different ideas. CMMC is the contractor certification. FedRAMP Moderate equivalency is a cloud-provider requirement that *sits inside* CMMC Level 2. They reference the same Moderate baseline, but they are not interchangeable credentials. ## Can FedRAMP and CMMC help each other? Yes — and this is where companies save real time and money. Because **NIST SP 800-171 is a subset and adaptation of NIST SP 800-53**, a large share of the work overlaps. If you have built one program well, you are not starting from zero on the other. The high-reuse areas are the same security fundamentals both frameworks insist on: - **Access control and identity** — MFA, least privilege, account management, access reviews - **Audit and accountability** — centralized logging, log retention, time synchronization - **Configuration management** — baselines, change control, vulnerability and patch management - **Incident response** — a tested IR plan, reporting workflows, and evidence of exercises - **System and communications protection** — encryption in transit and at rest, boundary protection - **Policies and procedures** — the same core control narratives, mapped to a different catalog The differences are in **packaging, assessor rigor, and scope**. FedRAMP demands a heavyweight authorization package — System Security Plan (SSP), Security Assessment Plan and Report (SAP/SAR), and Plan of Action and Milestones (POA&M) — plus continuous monitoring after authorization. CMMC is lighter on documentation but ties certification to a contract and an SPRS affirmation, and at Level 3 brings in a government assessor. This is the problem **Boundera** is built to solve. Teams rarely fail these programs because they are insecure; they fail because they cannot produce a clean, consistent, mapped evidence package fast enough. Boundera connects your systems, pulls evidence once, and maps that single evidence set to **both** NIST 800-53 and NIST 800-171 — so the controls you implement for FedRAMP carry straight into your CMMC scope instead of being rebuilt by hand in another spreadsheet. For a broader side-by-side that adds SOC 2 and StateRAMP to the picture, see [FedRAMP vs SOC 2 vs CMMC vs StateRAMP](/blog/rev5/fedramp-vs-soc2-vs-cmmc-vs-stateramp). To go deep on the FedRAMP side specifically, start with the [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025), and for the package itself, read [FedRAMP documentation explained](/blog/rev5/fedramp-documentation-ssp-sap-sar-poam). ## Frequently asked questions ### Do I need both FedRAMP and CMMC? Only if your situation calls for both. You need FedRAMP if you operate a cloud service that federal agencies will use. You need CMMC if you hold a DoD contract that involves FCI or CUI. A cloud SaaS vendor that wins defense contracts and processes CUI can end up needing FedRAMP for the agency sale *and* CMMC obligations within the defense supply chain, but many companies need only one. ### Is CMMC a replacement for FedRAMP? No. CMMC certifies a contractor's protection of FCI/CUI; FedRAMP authorizes a cloud service for federal use. They certify different objects, use different control frameworks (800-171 vs 800-53), and have different assessors. Holding one does not satisfy the other. ### What is the difference between a 3PAO and a C3PAO? A **3PAO** is a Third-Party Assessment Organization recognized to assess cloud services for FedRAMP. A **C3PAO** is a Certified Third-Party Assessment Organization authorized to assess defense contractors for **CMMC Level 2**. The names are similar but they operate in different programs, against different standards. ### Does FedRAMP Moderate equivalency satisfy CMMC? Not on its own. FedRAMP Moderate equivalency is the bar a *cloud provider* must clear when it handles CUI under DFARS 252.204-7012 — and that requirement is built into CMMC Level 2. But the contractor still has to achieve its own CMMC status. Equivalency addresses the cloud component, not the entire CMMC obligation. ### When did CMMC requirements start appearing in contracts? The CMMC program rule (32 CFR Part 170) is final, and the DFARS clause **252.204-7021 became effective November 10, 2025**. From that date, DoD began phasing CMMC requirements into applicable solicitations over a multi-year, four-phase rollout, so not every contract carries a CMMC requirement immediately. ### Which CMMC level do I need? It depends on the data and the contract. Handling only FCI generally means **Level 1** (annual self-assessment). Handling CUI means **Level 2** (the 110 NIST 800-171 requirements, met by self-assessment or a C3PAO assessment depending on the contract). A narrow set of high-priority programs require **Level 3**, which adds NIST 800-172 requirements assessed by DIBCAC. Your solicitation specifies the required level. ### Are FedRAMP impact levels the same as CMMC levels? No, and mixing them is a common error. FedRAMP in 2026 uses a single **"FedRAMP Certified"** label with **Certification Classes A, B, C, and D** — there are no numbered FedRAMP "levels." CMMC has its own **Levels 1, 2, and 3**. The "Moderate" baseline referenced in FedRAMP equivalency is a control baseline, not a CMMC level. ### Can the same evidence support both programs? Largely, yes. Because NIST 800-171 derives from NIST 800-53, controls for identity, logging, configuration management, incident response, and encryption overlap heavily. The smart approach is to collect evidence once and map it to both frameworks, which is exactly what Boundera automates. ## Sources - [FedRAMP.gov — official program site](https://www.fedramp.gov/) - [FedRAMP.gov — Understanding Baselines and Impact Levels](https://www.fedramp.gov/understanding-baselines-and-impact-levels/) - [DoD CIO — Cybersecurity Maturity Model Certification](https://dodcio.defense.gov/CMMC/) - [Federal Register — CMMC Program final rule (32 CFR Part 170)](https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program) - [Federal Register — DFARS 2019-D041, DFARS 252.204-7021 (effective Nov 10, 2025)](https://www.federalregister.gov/documents/2025/09/10/2025-17359/defense-federal-acquisition-regulation-supplement-assessing-contractor-implementation-of) - [DoD CIO — FedRAMP Equivalency for Cloud Service Providers](https://dodcio.defense.gov/Portals/0/Documents/Library/FEDRAMP-EquivalencyCloudServiceProviders.pdf) - [NIST SP 800-171 — Protecting CUI in Nonfederal Systems](https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final) - [NIST SP 800-53 — Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) * * * _Last updated: June 2026. Written by the Boundera team. Boundera is an AI copilot for FedRAMP and CMMC._ ### FedRAMP vs StateRAMP (now GovRAMP): Federal vs State Cloud - URL: https://boundera.io/blog/rev5/fedramp-vs-stateramp-govramp - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:32Z - Reading time: 8 minutes - Main question: What is the difference between FedRAMP and StateRAMP (now GovRAMP)? - TL;DR: FedRAMP authorizes cloud services for U.S. federal agencies; StateRAMP - rebranded to GovRAMP in 2025 - does the same for state, local, and education governments. Both are built on NIST SP 800-53 Rev. 5, require a 3PAO assessment and continuous monitoring, and use Low/Moderate/High impact levels. A FedRAMP authorization can be leveraged toward GovRAMP Ready status with minimal extra effort. - Excerpt: FedRAMP authorizes cloud for federal agencies; StateRAMP (rebranded GovRAMP in 2025) covers state, local, and education buyers. Compare scope, reciprocity, and which you need. # FedRAMP vs StateRAMP (now GovRAMP): Federal vs State Cloud Compliance **FedRAMP authorizes cloud services for U.S. federal agencies; StateRAMP — rebranded to GovRAMP in 2025 — does the same job for state, local, and education (SLED) governments.** Both are built on NIST SP 800-53, both require a third-party (3PAO) assessment and continuous monitoring, and both use Low, Moderate, and High impact levels. The difference is who runs the program and who buys from you: FedRAMP is a federal government program, while GovRAMP is an independent nonprofit serving the public sector outside the federal space. **Key takeaways** - **StateRAMP is now GovRAMP.** The nonprofit announced the rebrand on February 14, 2025; "StateRAMP, Inc." remains the legal entity operating as GovRAMP, so existing memberships and authorizations carry over unchanged. - **FedRAMP = federal buyers; GovRAMP = state, local, tribal, and education buyers.** Pick based on who pays you. - **Both rest on NIST SP 800-53 Rev. 5** and use Low / Moderate / High impact levels with a 3PAO assessment and continuous monitoring (ConMon). - **Reciprocity flows one direction cleanly:** a FedRAMP authorization can be leveraged toward GovRAMP Ready status with minimal extra effort. GovRAMP also satisfies Texas TX-RAMP with full reciprocity. - **A key structural difference:** GovRAMP Ready statuses do not expire and do not require a government sponsor to obtain, whereas FedRAMP requires an agency relationship to reach an authorized state. ## What is the difference between FedRAMP and StateRAMP/GovRAMP? FedRAMP (the Federal Risk and Authorization Management Program) is the U.S. government's program for standardizing the security assessment and authorization of cloud products used by **federal agencies**. It is funded through the federal government and managed by the FedRAMP Program Management Office. StateRAMP — now **GovRAMP** — is an independent 501(c)(6) nonprofit that standardizes cloud security verification for **state, local, tribal, and education** governments. It was created in 2020 and modeled in part on FedRAMP, but it serves the SLED market that FedRAMP does not cover. The two programs share a technical foundation but differ in governance, transparency, and how a provider reaches an authorized state: | Dimension | FedRAMP | StateRAMP / GovRAMP | | --- | --- | --- | | Governing body | U.S. federal government program (FedRAMP PMO) | GovRAMP, an independent 501(c)(6) nonprofit (legally StateRAMP, Inc.) | | Who it serves | U.S. federal agencies | State, local, tribal, and education (SLED) governments | | Underlying framework | NIST SP 800-53 Rev. 5 | NIST SP 800-53 Rev. 5 | | Impact levels | Low, Moderate, High | Low, Moderate, High (High Impact expanding in 2026) | | Independent assessment | 3PAO required | 3PAO required | | Continuous monitoring | Required after authorization | Required to maintain status | | Sponsor to authorize | Agency relationship required | Government sponsor or Approvals Committee for Authorized; Ready needs no sponsor | | Status expiration | Ready window is time-bound; sponsorship needed to advance | Ready status does not expire | | Documentation visibility | Visible to sponsoring federal agencies | SLED governments can view security posture and ConMon reporting | | Cost ballpark | Six to seven figures over the lifecycle | Generally lower; nonprofit provides templates and PMO support | > Source: [How Does GovRAMP Compare to FedRAMP? — govramp.org](https://govramp.org/blog/how-does-stateramp-compare-to-fedramp/) and [FedRAMP.gov](https://www.fedramp.gov/) For a wider view that also covers SOC 2 and CMMC, see [FedRAMP vs SOC 2 vs CMMC vs StateRAMP](/blog/rev5/fedramp-vs-soc2-vs-cmmc-vs-stateramp). ## Is StateRAMP now GovRAMP? Yes. On February 14, 2025, StateRAMP announced it would rebrand to **GovRAMP**. The organization explained that the name "StateRAMP" no longer captured the full scope of its mission, which supports a "whole-of-state" approach spanning state, local, tribal, and education entities — not just states. A few practical points that matter for providers: - **The legal entity did not change.** StateRAMP, Inc. continues to exist and now operates as (dba) GovRAMP. Every existing contract, membership, and authorization remains valid. - **Branding rolled out gradually** through 2025, which is why you may still see "StateRAMP" in older PDFs, templates, and third-party references. The current program name on [govramp.org](https://govramp.org/) is GovRAMP. - **Search both names.** When researching state participation, reciprocity, or the authorized product list, "StateRAMP" and "GovRAMP" refer to the same program. If you built a compliance plan around "StateRAMP" before 2025, nothing about the technical requirements changed — only the name. ## Which do you need: FedRAMP or GovRAMP? Choose based on who your customer is, not on which sounds more rigorous. - **Sell to federal agencies → FedRAMP.** If a U.S. federal civilian or defense agency is buying your cloud service, FedRAMP is the gate. There is no GovRAMP substitute for a federal contract. - **Sell to state, county, city, K-12, or higher-ed buyers → GovRAMP.** SLED procurement increasingly asks for a GovRAMP Ready or Authorized status to shorten security reviews. - **Sell into Texas → GovRAMP covers TX-RAMP.** Texas law requires cloud vendors serving the state to be TX-RAMP authorized, and TX-RAMP grants full reciprocity to GovRAMP. A GovRAMP Ready or Authorized status automatically satisfies TX-RAMP. - **Sell to both federal and SLED → do FedRAMP, then leverage it into GovRAMP.** The reuse path is efficient (covered below). Some providers pursue GovRAMP first because it has no agency-sponsor requirement for Ready status and the nonprofit PMO actively supplies templates and support — a lower barrier to a verifiable status than federal authorization. If federal demand later materializes, the control work transfers heavily to FedRAMP. ## Is there reciprocity between FedRAMP and GovRAMP? Reciprocity exists and is strongest in the **FedRAMP → GovRAMP** direction. Because both programs sit on the same NIST SP 800-53 Rev. 5 baseline, an organization holding a FedRAMP authorization can leverage its existing package and documentation to obtain **GovRAMP Ready** status with minimal additional effort. What that means in practice: - **A completed FedRAMP package is most of a GovRAMP package.** The SSP, boundary diagram, policies, and 3PAO evidence map across, since the underlying control set is shared. - **GovRAMP feeds state-level reciprocity.** GovRAMP statuses satisfy Texas TX-RAMP with full reciprocity, and a growing list of participating governments recognizes GovRAMP as their accepted standard — so one GovRAMP effort can clear multiple state requirements. - **Reciprocity is not automatic in reverse.** A GovRAMP status does not by itself produce a FedRAMP authorization; federal authorization still runs through the FedRAMP process and (under the 2026 rules) a chosen Certification Class. But the evidence you built is reusable. One transparency difference worth noting: FedRAMP documentation is visible only to the sponsoring federal agencies, while GovRAMP gives participating SLED governments visibility into a provider's security posture and continuous monitoring reporting. That openness is part of why GovRAMP works as a shared marketplace for state buyers. ## How GovRAMP and FedRAMP statuses actually work Both programs use verified "Ready" and "Authorized" states, but the path to each differs — and this is where teams most often plan wrong. **GovRAMP statuses** progress through Ready, In Process, Provisional, and Authorized: - **Ready** signals a provider meets minimum requirements. It does **not** expire and does **not** require a government sponsor or contract to obtain. - **Authorized** is the highest verification level. It requires a complete security package (SSP, boundary diagram, full policies and procedures) approved by either a Government Sponsor or the GovRAMP Approvals Committee. **FedRAMP** requires an agency relationship to move toward an authorized state, and the path now runs through a Certification Class (A, B, C, or D) under the 2026 consolidated rules, ending in a single **FedRAMP Certified** designation. Because the documentation engine is the same NIST 800-53 control set, the smart play is to build evidence once and map it to whichever program your buyers require. This is exactly the problem Boundera's copilot is built for: connecting your systems, pulling control evidence consistently, and mapping that evidence to either a FedRAMP package or a GovRAMP package without rebuilding from scratch. For where FedRAMP statuses are published, see our [FedRAMP Marketplace explained](/blog/rev5/fedramp-marketplace-explained) guide; for budgeting the federal path, see [FedRAMP cost](/blog/20x/fedramp-cost-2026). ## Frequently asked questions ### Did StateRAMP change its name to GovRAMP? Yes. StateRAMP announced the rebrand to GovRAMP on February 14, 2025. The legal entity remains StateRAMP, Inc., operating as GovRAMP, so all existing authorizations and memberships continue without disruption. The current program name is GovRAMP. ### Why did StateRAMP rebrand to GovRAMP? The organization said "StateRAMP" no longer captured the full scope of its mission. GovRAMP supports a whole-of-state approach across state, local, tribal, and education governments — not just state agencies — so the broader "Gov" name reflects the wider public-sector audience it serves. ### Is GovRAMP the same as FedRAMP? No, but they are closely related. Both are built on NIST SP 800-53 Rev. 5, require a 3PAO assessment, use Low/Moderate/High impact levels, and require continuous monitoring. FedRAMP is a federal government program for federal agencies; GovRAMP is an independent nonprofit serving SLED governments. ### Can a FedRAMP authorization be used for GovRAMP? Largely, yes. A FedRAMP-authorized provider can leverage its existing documentation to reach GovRAMP Ready status with minimal additional effort, because both programs share the same NIST 800-53 baseline. The reverse is not automatic — GovRAMP alone does not grant FedRAMP authorization. ### Does GovRAMP satisfy Texas TX-RAMP? Yes. TX-RAMP recognizes GovRAMP with full reciprocity. If you hold GovRAMP Ready or Authorized status, you are granted the corresponding TX-RAMP certification, which is required for cloud vendors serving the state of Texas. ### Who needs GovRAMP instead of FedRAMP? Providers selling cloud services to state, county, city, K-12, or higher-education buyers typically need GovRAMP rather than FedRAMP. FedRAMP is required only when selling to U.S. federal agencies. Many providers selling to both pursue FedRAMP and leverage it into GovRAMP. ### Does GovRAMP Ready status expire? No. Unlike the time-bound FedRAMP Ready window, GovRAMP Ready statuses do not expire, and a provider does not need a government sponsor or an active government contract to obtain Ready status. (Note: beginning January 1, 2026, GovRAMP's Progressing Snapshot Program added requirements to keep listed products actively advancing toward a verified status.) ### Is GovRAMP based on NIST 800-53? Yes. GovRAMP has adopted NIST SP 800-53 Rev. 5 as the foundation for its standards — the same control catalog FedRAMP uses — which is why evidence and documentation transfer so readily between the two programs. ## Sources - [GovRAMP — official program site (formerly StateRAMP)](https://govramp.org/) - [StateRAMP Announces Rebrand to GovRAMP — govramp.org](https://govramp.org/blog/stateramp-announces-rebrand-to-govramp-reflecting-mission-to-unite-public-and-private-sectors-in-advancing-cybersecurity/) - [How Does GovRAMP Compare to FedRAMP? — govramp.org](https://govramp.org/blog/how-does-stateramp-compare-to-fedramp/) - [GovRAMP for State and Local Governments & Education — govramp.org](https://govramp.org/governments/) - [FedRAMP — fedramp.gov](https://www.fedramp.gov/) - [FedRAMP Consolidated Rules for 2026 (Public Preview) — fedramp.gov](https://www.fedramp.gov/preview/2026/scope/) - [NIST SP 800-53 Rev. 5 — NIST](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP vs FISMA: How They Differ and How They Connect - URL: https://boundera.io/blog/rev5/fedramp-vs-fisma - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:31Z - Reading time: 8 minutes - Main question: What is the difference between FedRAMP and FISMA? - TL;DR: FISMA is the federal law requiring agencies to secure and authorize their systems using the NIST Risk Management Framework. FedRAMP is the government-wide program that applies that same NIST 800-53 standard to commercial cloud services so one assessment can be reused across agencies. FISMA defines what must be achieved; FedRAMP is how a cloud provider proves it once for the whole government. - Excerpt: FISMA is the federal security law; FedRAMP is the cloud program built to satisfy it. Here's how they differ, overlap, and both rely on NIST 800-53. # FedRAMP vs FISMA: How They Differ and How They Connect **FISMA is the federal law; FedRAMP is the cloud program built to satisfy it.** FISMA (the Federal Information Security Modernization Act) requires every federal agency to secure and authorize its information systems using the NIST Risk Management Framework. FedRAMP is the government-wide program that applies that same security standard to commercial cloud services so that one assessment can be reused across many agencies instead of each agency starting from scratch. In short: FISMA tells agencies *what* security outcome they must achieve, and FedRAMP is *how* a cloud provider proves it once for the whole government. Both rest on the same control catalog, NIST SP 800-53. **Key takeaways** - FISMA is law (codified in [44 U.S.C. Chapter 35, Subchapter II](https://www.congress.gov/)); FedRAMP is a program established by the FedRAMP Authorization Act of 2022 ([Public Law 117-263](https://www.fedramp.gov/docs/authority/law/)) and run by GSA. - FISMA applies to all federal agencies and their information systems; FedRAMP applies to cloud services agencies buy and use. - Both use the same baseline: NIST SP 800-53 controls and the NIST Risk Management Framework. - FedRAMP's core value is *reuse*: one authorization package can be leveraged by many agencies, while a pure FISMA ATO is granted by a single agency for its own use. - In 2026 terminology, an authorized cloud service is "FedRAMP Certified," with offerings grouped into Certification Classes rather than numbered levels. ## What is the difference between FedRAMP and FISMA? FISMA is a statute that makes information security a legal obligation for federal agencies. FedRAMP is an operational program that standardizes how cloud services meet that obligation. FISMA, originally enacted in 2002 and modernized in 2014, directs each agency to inventory its systems, categorize them by risk, implement security controls, and have a senior official formally accept the residual risk through an Authority to Operate (ATO). It hands the technical "how" to NIST, which publishes the Risk Management Framework (RMF) and the SP 800-53 control catalog that agencies must follow. FedRAMP takes that framework and applies it specifically to cloud. Instead of every agency independently assessing the same SaaS, IaaS, or PaaS product, a cloud service provider (CSP) goes through one rigorous assessment by an accredited third party. The result is a reusable authorization package. The FedRAMP program was formally written into law by the FedRAMP Authorization Act, enacted December 23, 2022 as part of [Public Law 117-263](https://www.fedramp.gov/docs/authority/law/), and is implemented under OMB Memorandum [M-24-15](https://www.fedramp.gov/docs/authority/scope/). | Dimension | FISMA | FedRAMP | | --- | --- | --- | | What it is | A federal law on information security | A government-wide cloud authorization program | | Legal basis | 44 U.S.C. Chapter 35 (FISMA); RMF via NIST | FedRAMP Authorization Act, Public Law 117-263; OMB M-24-15 | | Who it applies to | All federal agencies and their information systems | Cloud services (SaaS/IaaS/PaaS) used by agencies | | Security standard | NIST SP 800-53 + NIST RMF | NIST SP 800-53 baselines (with FedRAMP parameters) | | Who assesses | Agency or its contractor; agency authorizing official decides | Accredited third-party assessor (3PAO); agency or FedRAMP authorizes | | Reuse | ATO is typically agency-specific | One package reused across many agencies | | Outcome | Agency ATO | "FedRAMP Certified" status, listed on the FedRAMP Marketplace | > Source: [FedRAMP Authorization Act, FedRAMP.gov](https://www.fedramp.gov/docs/authority/law/) ## How do FedRAMP and FISMA relate to NIST 800-53? NIST SP 800-53 is the common foundation both rely on. FISMA points agencies to NIST for the controls; FedRAMP takes those same controls and packages them into standardized cloud baselines. Under FISMA, agencies categorize each system using FIPS 199 (Low, Moderate, or High impact based on confidentiality, integrity, and availability) and then select a corresponding set of [NIST SP 800-53](https://csrc.nist.gov/) controls. FedRAMP uses the very same catalog but defines its own baselines tuned for cloud and often sets stricter parameter values than the base NIST baseline. So a control like multi-factor authentication or audit logging appears in both worlds; FedRAMP simply pins down exactly how a multi-tenant cloud service must implement and evidence it. This shared spine is why the two programs interlock cleanly. When a CSP earns FedRAMP Certified status, the agency consuming that service can inherit the cloud layer's controls into its own FISMA package rather than re-assessing the provider. The agency still owns its FISMA responsibilities for everything it builds on top, but it does not have to re-prove the underlying cloud platform. ## Do you need both FedRAMP and FISMA? If you are a federal agency, FISMA is mandatory and is never optional. If you are a cloud provider selling to agencies, you effectively need FedRAMP so that your customers can meet their FISMA obligations. The two are not competing checkboxes; they are two sides of the same transaction: - **Agencies** must comply with FISMA for every system they operate, including systems hosted in the cloud. They cannot opt out. - **Cloud providers** are not directly bound by FISMA the way agencies are, but agencies can only use a cloud service in scope of FedRAMP if it is FedRAMP authorized. Per OMB [M-24-15](https://www.fedramp.gov/docs/authority/scope/), agencies "must obtain and maintain a FedRAMP authorization for cloud services that are within the scope of FedRAMP." So for a CSP, FedRAMP is the practical price of entry to the federal cloud market. A useful way to think about it: FISMA is the destination (a securely authorized agency system) and FedRAMP is a fast lane for the cloud portion of the journey. A CSP that becomes FedRAMP Certified is essentially pre-clearing the FISMA security review for the cloud layer on behalf of every agency customer. Note that not every agency use of an internet service is in scope. M-24-15 sets scope indicators and exclusion categories: single-agency systems, certain social media and communications uses, search engines, information providers, and negligible-risk services can fall outside FedRAMP even though the agency's broader FISMA duties still apply. Scope is determined by the agency's specific use case, not by the product itself. ## What does authorization look like under each? A FISMA ATO is granted by one agency for its own system; a FedRAMP authorization produces a reusable package and a public Marketplace listing. Under straight FISMA, an agency follows the NIST RMF: categorize the system, select and implement 800-53 controls, assess them (often via the agency's own staff or a contractor), and then the agency's Authorizing Official issues an ATO accepting the risk. That ATO is generally scoped to that one agency and that one system. Under FedRAMP, the cloud provider's offering is assessed by an accredited third-party assessment organization (3PAO) against a FedRAMP baseline. The provider produces a standardized authorization package, and once authorized the service is FedRAMP Certified and listed on the [FedRAMP Marketplace](https://www.fedramp.gov/marketplace) so any agency can review and reuse it. In current 2026 terminology, FedRAMP uses a single "FedRAMP Certified" label and groups offerings into Certification Classes; you should always confirm the latest naming on [fedramp.gov](https://www.fedramp.gov/), since the program is actively consolidating its rules through 2028. For a full walk-through of the package and process, see our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025) and the deeper dive into the deliverables in [FedRAMP documentation explained](/blog/rev5/fedramp-documentation-ssp-sap-sar-poam). ## Where FedRAMP, FISMA, and other frameworks fit together FedRAMP and FISMA are a matched pair for federal cloud; other frameworks like SOC 2, CMMC, and StateRAMP serve different buyers. If you are mapping out which credential your business actually needs, our breakdown of [FedRAMP vs SOC 2 vs CMMC vs StateRAMP](/blog/rev5/fedramp-vs-soc2-vs-cmmc-vs-stateramp) covers the commercial and DoD paths in detail. The short version: FedRAMP and FISMA are the federal-agency cloud track, built on NIST 800-53; SOC 2 targets commercial trust; CMMC governs the DoD supply chain; and StateRAMP serves state and local government. The good news for builders is that the underlying control work is highly reusable. A strong NIST 800-53-aligned program built for FISMA and FedRAMP gives you most of what you need to package other frameworks later. ## Frequently asked questions ### Is FedRAMP the same as FISMA? No. FISMA is a federal law that requires agencies to secure and authorize their information systems using the NIST Risk Management Framework. FedRAMP is a government-wide program that applies the same NIST SP 800-53 security standard to commercial cloud services so a single authorization can be reused across agencies. They are tightly connected but not interchangeable. ### Does FedRAMP satisfy FISMA? For the cloud layer, largely yes. A FedRAMP authorization is built on the same NIST controls FISMA requires, so agencies can inherit the cloud provider's authorized controls into their own FISMA package instead of re-assessing them. The agency still has FISMA responsibilities for whatever it builds on top of the cloud service. ### Who has to comply with FISMA? All U.S. federal executive-branch agencies and their information systems, including systems they host in the cloud. FISMA compliance is a legal obligation under 44 U.S.C. Chapter 35 and is not optional for agencies. ### Do cloud providers have to follow FISMA directly? Not in the same direct way agencies do. Cloud providers pursue FedRAMP so their agency customers can meet their FISMA obligations. Under OMB M-24-15, agencies must use FedRAMP-authorized services for cloud use cases that are in scope, which makes FedRAMP the practical requirement for selling cloud to the government. ### What standard do both FedRAMP and FISMA use? Both rely on NIST SP 800-53 controls and the NIST Risk Management Framework, with systems categorized by FIPS 199 impact level. FedRAMP defines cloud-specific baselines drawn from that same catalog and often sets stricter control parameters than the base NIST baseline. ### Is FedRAMP mandatory for selling cloud to the government? For in-scope cloud use cases, effectively yes. OMB M-24-15 directs agencies to obtain and maintain a FedRAMP authorization for cloud services within FedRAMP's scope. Whether a specific use case is in scope depends on the agency's use of the service, not the product alone, per the FedRAMP scope guidance. ### What is an ATO, and how does it relate to FISMA and FedRAMP? An Authority to Operate (ATO) is a senior official's formal decision to accept the security risk of operating a system. FISMA requires agencies to authorize their systems this way. FedRAMP produces a reusable authorization package that streamlines the cloud portion of that decision for every agency that leverages it. ### Where can I confirm current FedRAMP terminology? Always verify on the official program site, [fedramp.gov](https://www.fedramp.gov/). In 2026 the program uses a single "FedRAMP Certified" label and Certification Classes, and is consolidating its rules through 2028, so naming and requirements continue to evolve. ## Sources - [FedRAMP Authorization Act and statutory basis — FedRAMP.gov](https://www.fedramp.gov/docs/authority/law/) - [Scope of FedRAMP (OMB M-24-15) — FedRAMP.gov](https://www.fedramp.gov/docs/authority/scope/) - [FedRAMP Marketplace — FedRAMP.gov](https://www.fedramp.gov/marketplace) - [NIST SP 800-53 and the Risk Management Framework — NIST CSRC](https://csrc.nist.gov/) - [FISMA, 44 U.S.C. Chapter 35 — Congress.gov](https://www.congress.gov/) --- _Last updated: June 2026. Written by the Boundera team. Boundera is an AI copilot for FedRAMP — verify current program terminology on fedramp.gov before you submit._ ### FedRAMP vs SOC 2: Key Differences and Which You Need - URL: https://boundera.io/blog/20x/fedramp-vs-soc2 - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:30Z - Reading time: 9 minutes - Main question: What's the difference between FedRAMP and SOC 2, and which do I need? - TL;DR: FedRAMP is a mandatory U.S. government authorization built on NIST SP 800-53 for selling cloud to federal agencies. SOC 2 is a voluntary, commercial CPA attestation against the AICPA Trust Services Criteria. Sell to government, you need FedRAMP; sell to enterprise, you need SOC 2; many companies eventually need both. - Excerpt: FedRAMP authorizes cloud for federal agencies; SOC 2 is a voluntary commercial attestation. Here's how they differ and which you need. # FedRAMP vs SOC 2: Key Differences and Which You Need FedRAMP and SOC 2 solve different problems. FedRAMP is a U.S. government program that authorizes cloud services for sale to federal agencies, built on NIST SP 800-53 controls. SOC 2 is a voluntary, commercial attestation against the AICPA Trust Services Criteria that you show to enterprise customers. If you sell cloud to federal agencies, you need FedRAMP. If you sell to private-sector businesses, SOC 2 is usually the right first credential. Many companies eventually need both. **Key takeaways** - **FedRAMP is mandatory** to provide most cloud services to U.S. federal agencies; **SOC 2 is voluntary** and driven by commercial buyers, not by law. - **FedRAMP is built on NIST SP 800-53**; **SOC 2 is built on the AICPA Trust Services Criteria** (Security plus optional categories). - **FedRAMP is assessed by a FedRAMP-recognized assessor (3PAO)** and certified through the government; **SOC 2 is examined by a licensed CPA firm** and produces a private report. - **FedRAMP is far more expensive and slower** — typically hundreds of thousands to millions of dollars over a multi-month-to-multi-year lifecycle — while a SOC 2 Type II commonly lands in the tens of thousands over a few months. - In 2026, FedRAMP uses a single **"FedRAMP Certified"** label and **Certification Classes A, B, C, and D** in place of the old numbered impact levels. ## What's the difference between FedRAMP and SOC 2? FedRAMP is a federal authorization; SOC 2 is a commercial attestation. The simplest way to keep them straight is to ask who is asking for it. A government agency asks for FedRAMP because it is required by federal policy. A private-sector customer asks for SOC 2 because their security and procurement teams want independent assurance before they trust you with their data. The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program, run under the General Services Administration, that gives federal agencies a standardized way to assess and authorize cloud services. Its security requirements come from NIST SP 800-53, and the outcome is a reusable authorization package an agency can rely on to put your service into production. SOC 2 (System and Organization Controls 2) is an attestation engagement performed by an independent CPA firm against the AICPA's Trust Services Criteria. There is no government program behind it, no public registry, and no statutory mandate. It exists because the market wanted a consistent, auditor-backed way to evaluate a service organization's controls. | Dimension | FedRAMP | SOC 2 | | --- | --- | --- | | **Purpose** | Authorize cloud services for U.S. federal agency use | Give commercial customers assurance over a service organization's controls | | **Who requires it** | Federal agencies (mandatory to sell most cloud to government) | Enterprise/commercial buyers (voluntary, market-driven) | | **Underlying framework** | NIST SP 800-53 control baselines | AICPA Trust Services Criteria | | **Assessor** | FedRAMP-recognized 3PAO + government certification | Independent licensed CPA firm | | **Output** | FedRAMP Certification + reusable authorization package | Private SOC 2 report (Type I or Type II) | | **Visibility** | Public listing on the FedRAMP Marketplace | Private report shared under NDA | | **Typical cost** | Six to seven figures across the lifecycle | Low five figures for most SaaS | | **Typical timeline** | Many months to over a year | Roughly one to four months (plus the audit window for Type II) | > Source: [FedRAMP.gov](https://www.fedramp.gov/) and the [AICPA SOC 2 resources](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2). ## What is SOC 2, and what are Type I and Type II? SOC 2 is a report on how well a service organization's controls meet the AICPA Trust Services Criteria. The criteria are organized into five categories: Security (the only required one, also called the common criteria), Availability, Processing Integrity, Confidentiality, and Privacy. You scope your report to the categories that matter to your customers, and a CPA firm examines whether your controls are suitably designed and operating. There are two report types, and the difference is about time: - **SOC 2 Type I** evaluates whether your controls are *suitably designed* at a single point in time. It is faster and cheaper, and useful as a first milestone, but it does not prove the controls actually ran. - **SOC 2 Type II** evaluates whether those controls are *designed and operating effectively* over a review period — commonly three to twelve months. This is what most serious enterprise buyers want, because it shows your security worked over time, not just on the audit date. A SOC 2 report is confidential. You typically share it under NDA during a vendor security review. There is no public database of SOC 2 reports, which is a core difference from FedRAMP's public Marketplace. ## What is FedRAMP, and why is it stricter? FedRAMP is stricter because it is a government authorization, not a private attestation, and because it is built on the full weight of NIST SP 800-53. Where SOC 2 lets you scope to a handful of Trust Services Criteria, FedRAMP requires you to implement and document a complete control baseline, have it independently tested, and then maintain it through continuous monitoring (ConMon) for the life of the authorization. The FedRAMP process generally runs through these stages: - **Implement a control baseline** drawn from NIST SP 800-53 and document it in a System Security Plan (SSP). - **Get assessed by a FedRAMP-recognized third-party assessment organization (3PAO)**, which produces a Security Assessment Report and Plan of Action and Milestones (POA&M). - **Earn a FedRAMP Certification**, which produces a reusable authorization package an agency can accept. - **Maintain continuous monitoring** with ongoing scanning, reporting, and remediation — FedRAMP is explicitly not "one and done." In 2026, the terminology changed. Per FedRAMP's public notice on authorization designations (NTC-0004), there is now a **single official label — "FedRAMP Certified"** — for all FedRAMP authorizations, replacing earlier proposals for separate names. FedRAMP also retired numbered "levels" in favor of **Certification Classes A, B, C, and D**, which describe the depth of the assessment rather than a guaranteed security category. The legacy LI-SaaS and Low baselines map into Class B, Moderate into Class C, and High into Class D, with Class A as a new pilot baseline. Authorized services appear publicly on the FedRAMP Marketplace. ## Can SOC 2 work be reused for FedRAMP? Yes — partly. SOC 2 and FedRAMP draw on the same underlying security disciplines, so much of the *operational* work you do for SOC 2 carries over. What does not carry over is the FedRAMP package itself: a SOC 2 report is never a substitute for a FedRAMP authorization, and no agency will accept it as one. In our work helping cloud teams build authorization packages, the controls that transfer most cleanly are the day-to-day security operations that both frameworks expect to see running: - **Identity and access** — MFA enforcement, single sign-on, least privilege, and periodic access reviews. - **Logging and monitoring** — centralized logs, alerting, retention, and time synchronization. - **Vulnerability management** — recurring scanning, patch SLAs, and tracked remediation. - **Change management** — reviewed pull requests, CI checks, and release records. - **Incident response** — a tested IR plan and evidence of exercises. - **Backup and recovery** — tested restores and documented RPO/RTO targets. What changes is the *format, rigor, and depth* of evidence. FedRAMP demands a far larger control set, government-specific documentation, a 3PAO assessment instead of a CPA examination, and machine-friendly continuous evidence. A team with a mature SOC 2 Type II program has a real head start on the habits FedRAMP needs, but it still faces a substantial gap in scope and package production. This is exactly the gap Boundera's AI copilot is built to close — connecting your systems, pulling evidence consistently, mapping it to FedRAMP controls, and drafting the documentation so you are not rebuilding the package from scratch. ## Which do you need — FedRAMP or SOC 2? Choose based on who pays you. The two frameworks serve different buyers, so the answer is rarely "both at once" — it is usually a sequence. - **Selling cloud to U.S. federal agencies?** You need **FedRAMP**. SOC 2 will not satisfy a federal procurement requirement. - **Selling to commercial and enterprise customers?** You need **SOC 2** (Type II), the fastest way to clear vendor security reviews. - **Early-stage SaaS that wants federal business eventually?** Do **SOC 2 first** to unlock revenue, then pursue FedRAMP once you have a real federal pipeline. - **Already have federal demand?** Go **FedRAMP-first** and close gaps fast; the operational discipline also makes a later SOC 2 straightforward. A useful rule: do not build compliance no one is asking you for. FedRAMP is a major, ongoing investment, and starting it without genuine federal demand burns months and budget. SOC 2 is the lower-cost trust signal that keeps commercial deals moving while you decide whether federal is worth the climb. For a wider view that adds CMMC and StateRAMP to the picture, see our [FedRAMP vs SOC 2 vs CMMC vs StateRAMP](/blog/rev5/fedramp-vs-soc2-vs-cmmc-vs-stateramp) comparison. ## Cost and timeline compared FedRAMP costs dramatically more and takes dramatically longer than SOC 2. A SOC 2 Type II is a routine, repeatable audit measured in weeks-to-months and tens of thousands of dollars. FedRAMP is a program-level commitment measured in months-to-years and six-to-seven figures, with recurring continuous-monitoring costs every year after authorization. | Factor | FedRAMP | SOC 2 | | --- | --- | --- | | **Up-front cost** | Six to seven figures, varying by Certification Class | Commonly low five figures for SaaS | | **Recurring cost** | Annual continuous monitoring (a major ongoing line item) | Annual re-examination (Type II refresh) | | **Initial timeline** | Many months to well over a year | Roughly 1–4 months, plus the Type II review window | | **Who assesses** | FedRAMP-recognized 3PAO + government | Independent CPA firm | | **Lasts because** | Continuous monitoring is required indefinitely | Buyers expect a fresh report each year | Two cost drivers matter most for FedRAMP: your **Certification Class** (the former Low/Moderate/High baselines, now Classes B/C/D, each requiring more evidence) and **continuous monitoring**, which scales with the size of your system boundary and recurs every year. For a full breakdown of both, see our analysis of [FedRAMP cost](/blog/20x/fedramp-cost-2026) and the end-to-end process in our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025). ## Frequently asked questions ### Is SOC 2 required by law? No. SOC 2 is a voluntary, market-driven attestation against the AICPA Trust Services Criteria. No statute requires it. Companies pursue it because enterprise customers ask for it during vendor security reviews, and it has become a de facto trust signal for B2B SaaS. ### Is FedRAMP required by law? In practice, yes, for the federal market. Federal policy requires agencies to use FedRAMP-authorized cloud services for most cloud offerings, and the FedRAMP Authorization Act codified the program. If you want to sell most cloud services to U.S. federal agencies, FedRAMP Certification is the gate you must pass. ### Does a SOC 2 report satisfy FedRAMP? No. A SOC 2 report does not meet FedRAMP requirements and cannot replace a FedRAMP authorization. They use different frameworks (Trust Services Criteria vs NIST SP 800-53), different assessors (CPA firm vs 3PAO), and produce different outputs. SOC 2 work can reduce your FedRAMP effort, but it is never a substitute. ### Which is more expensive, FedRAMP or SOC 2? FedRAMP, by a wide margin. SOC 2 typically costs tens of thousands of dollars, while FedRAMP runs into six or seven figures across the lifecycle, plus recurring annual continuous-monitoring costs. The gap reflects FedRAMP's much larger control set, 3PAO assessment, and government oversight. ### Can I get both FedRAMP and SOC 2? Yes, and many cloud providers hold both. SOC 2 covers commercial customers and FedRAMP covers federal agencies. Most companies sequence them — SOC 2 first for commercial revenue, FedRAMP later when federal demand is real — because the SOC 2 operational discipline transfers into the FedRAMP effort. ### What replaced FedRAMP impact levels in 2026? FedRAMP retired numbered "levels" in favor of **Certification Classes A, B, C, and D** to avoid confusion with the Department of Defense Impact Level system. Classes describe the depth of the assessment, not a guaranteed security category. There is also now a single **"FedRAMP Certified"** label for all authorizations. ### Is a SOC 2 report public like a FedRAMP listing? No. A SOC 2 report is confidential and shared under NDA during sales and vendor reviews. FedRAMP authorizations are listed publicly on the FedRAMP Marketplace, where agencies and buyers can search for certified services. ## Sources - [FedRAMP.gov — official program site and Marketplace](https://www.fedramp.gov/) - [FedRAMP NTC-0004 — single "FedRAMP Certified" label and Certification Classes](https://www.fedramp.gov/notices/0004) - [NIST SP 800-53 — Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) - [AICPA — SOC 2 and the Trust Services Criteria](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2) * * * _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP Ready vs Authorized vs ATO: 2026 Labels - URL: https://boundera.io/blog/20x/fedramp-ready-vs-authorized - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:29Z - Reading time: 7 minutes - Main question: What is the difference between FedRAMP Ready, Authorized, Certified, and an agency ATO in 2026? - TL;DR: A FedRAMP Certification (the 2026 label that replaced 'FedRAMP Authorized') means FedRAMP has confirmed a cloud service's package is complete and reusable by agencies. It is NOT an agency Authority to Operate (ATO) - each agency still issues its own ATO. 'FedRAMP Ready' is being retired and replaced by a 'Preparation' listing state. - Excerpt: FedRAMP Ready, Authorized, Certified, and agency ATO explained for 2026 - including what changed under RFC-0020 and NTC-0004. # FedRAMP Ready vs Authorized vs ATO: What the Labels Mean in 2026 A **FedRAMP Certification** (the 2026 label that replaced "FedRAMP Authorized") means FedRAMP has assessed a cloud service's package and confirmed it is complete enough for federal agencies to reuse. It is **not** an agency Authority to Operate (ATO) — each agency still issues its own ATO before using the service. "FedRAMP Ready," meanwhile, is being retired and folded into a new **Preparation** listing state on the Marketplace. **Key takeaways** - In 2026, the official label for a FedRAMP authorization is **FedRAMP Certified** — a single label covering both Rev 5 and 20x. There is no separate "FedRAMP Validated." - A **FedRAMP Certification is not an agency ATO.** FedRAMP packages the security evidence; an agency Authorizing Official still makes the risk decision and issues the ATO. - The four assessment baselines are now **Certification Classes A, B, C, and D** — not "Low/Moderate/High levels" — to avoid confusion with DoD Impact Levels. - **"FedRAMP Ready" is retiring.** Providers early in the process now appear under a **Preparation** status on the Marketplace. - These changes come from **RFC-0020** and its outcome notice **NTC-0004**, formalized in the **FedRAMP Consolidated Rules for 2026 (CR26)**, expected by the end of June 2026. ## What's the difference between FedRAMP Ready and Authorized? Historically, FedRAMP used a series of Marketplace statuses to show where a cloud service offering sat in the process: **Ready**, **In Process**, and **Authorized**. In 2026 those labels have been overhauled, but the underlying idea is the same — they mark **progress through assessment**, not a guarantee of security or a license for any agency to use the service. Here is what each legacy status meant, and what it maps to in 2026: | Legacy status (pre-2026) | What it meant | 2026 equivalent | What it means now | | --- | --- | --- | --- | | FedRAMP Ready | A 3PAO confirmed the provider's package was likely capable of meeting requirements; an optional starting designation. | **Preparation** | The provider is doing the essential work to manage its security and privacy risks before formal assessment. "Ready" as a label is being retired. | | In Process | An agency or the program had begun an authorization and the package was under active review. | **Agency Authorization In Process** / **Assessment by FedRAMP** | An agency has notified FedRAMP it began an authorization, or FedRAMP is performing its final assessment (targeted at under 30 days for a complete package). | | Authorized | FedRAMP had granted an authorization and the service was listed as reusable by agencies. | **FedRAMP Certified** (Continuous Monitoring status) | FedRAMP has certified the package is complete and the provider is in ongoing continuous monitoring. This is the target end state. | > Source: [FedRAMP RFC-0020, FedRAMP Authorization Designations](https://www.fedramp.gov/rfcs/0020/) The most important distinction: **"Ready/Preparation" is the on-ramp, "Certified" is the destination.** A service in Preparation has not been authorized and should not be treated as cleared for federal use. A service that is FedRAMP Certified has a reviewed, reusable package — but, as the next section explains, that still is not the same as permission to operate inside a specific agency's system. ## Is FedRAMP authorization the same as an ATO? **No.** This is the single most common misconception in federal cloud procurement, and it is exactly why FedRAMP changed the terminology in 2026. A **FedRAMP Certification** means FedRAMP has packaged a cloud service provider's essential security information so an agency can decide whether to use the service. An **Authority to Operate (ATO)** is a separate decision made by an agency's Authorizing Official under the NIST Risk Management Framework and OMB Circular A-130. Only that official can authorize the operation of an information system for their agency's specific use. In FedRAMP's own words from RFC-0020, a FedRAMP authorization "is not a decision by an Authorizing Official that the service has been granted an Authorization to Operate (ATO)." The FedRAMP Board found that using the words "authorized" and "authorization" for both concepts created real risk — providers assumed certification was a government-wide ATO, and agency staff sometimes adopted services without reviewing the package or owning the risk. | | FedRAMP Certification | Agency ATO | | --- | --- | --- | | Who grants it | FedRAMP (within GSA) | An agency Authorizing Official | | What it confirms | The security package is complete and reusable | This agency accepts the risk of operating the system | | Scope | Government-wide reusable evidence | One agency's specific use and security category | | Required to sell to an agency | Effectively yes, as the basis | Yes — each agency issues its own | > Source: [FedRAMP RFC-0020, FedRAMP Authorization Designations](https://www.fedramp.gov/rfcs/0020/) A practical consequence: a FedRAMP Certification earned at one security category does **not** lock an agency into using the service at that category. FedRAMP explicitly encourages agencies to reuse a Certification package at a higher or lower security category than the one it was assessed against, after running their own NIST RMF Categorize step. The certification supplies the evidence; the agency owns the decision. ## What is FedRAMP Certified? **FedRAMP Certified** is the 2026 replacement for "FedRAMP Authorized." It is a single, official label that applies to both the legacy **Rev 5** path and the newer **FedRAMP 20x** path. Per NTC-0004, FedRAMP decided **not** to create separate "FedRAMP Validated" branding for 20x, because separate labels would create more procurement confusion, not less. Instead, both paths carry the FedRAMP Certified label, and the Marketplace provides filters so agencies can tell Rev 5 and 20x apart. The label traces directly to statute. The FedRAMP Authorization Act defines a FedRAMP authorization as "a certification that a cloud computing product or service has completed a FedRAMP authorization process." That is why the program now uses **FedRAMP Certification** for the authorization and **FedRAMP Certification Package** for the authorization package. Any cloud service with a FedRAMP Certification is FedRAMP authorized for statutory and regulatory purposes, including adequacy for an agency to use when authorizing operation of that service. A critical caveat FedRAMP repeats in both RFC-0020 and NTC-0004: **a FedRAMP Certification does not measure the overall security of a cloud service.** It indicates the depth and completeness of the assessment evidence available to agencies — not a security score, and not a substitute for an agency's own risk decision. ## What are FedRAMP Certification Classes A, B, C, and D? FedRAMP kept **four baselines** of assessment, but in 2026 it relabeled them as **Certification Classes A, B, C, and D** instead of FIPS 199 "Low / Moderate / High" levels. Per NTC-0004, FedRAMP deliberately avoided the words "levels" and numbers to prevent confusion with the DoD/DoW Impact Level (IL) system, and to reinforce that a class describes the **scope of the assessment**, not the total quality or security of the service. | Certification Class | Maps to legacy baseline | Notes | | --- | --- | --- | | **Class A** | New pilot baseline (Rev 5) | A new, lightweight pilot class introduced under CR26. | | **Class B** | Li-SaaS and Low | Combines the historical Li-SaaS and Low baselines. | | **Class C** | Moderate | The most common baseline for SaaS selling to agencies. | | **Class D** | High | The most sensitive federal data; deepest assessment. | > Source: [FedRAMP NTC-0004, Initial Outcome from RFC-0020](https://www.fedramp.gov/notices/0004/) NTC-0004 also clarifies that FedRAMP is **not** changing the underlying requirements of the baselines as part of this relabeling — only the names — and that 20x requirements will be aligned to these same classes in CR26. There will be a transition period where old and new labels are linked so the market can adjust. ## What changed in 2026? Several FedRAMP terminology and Marketplace changes landed together in early 2026 through RFC-0020 (and its sibling RFCs on the Marketplace and external frameworks), with outcomes formalized in NTC-0004: - **"FedRAMP Authorized" → "FedRAMP Certified."** One label, both Rev 5 and 20x. No "FedRAMP Validated." - **"FedRAMP Ready" → "Preparation."** The Ready designation is being retired in favor of a Preparation listing state on the Marketplace. - **Impact "levels" → "Certification Classes A/B/C/D."** Four baselines remain; the names changed to avoid clashing with DoD Impact Levels. - **Sharper Certification-vs-ATO line.** The program now reserves "authorization" language for the agency ATO under the NIST RMF, and uses "certification" for what FedRAMP does. - **Marketplace lifecycle redefined.** Rev 5 services move through Preparation → Agency Authorization In Process → Assessment by FedRAMP → Continuous Monitoring (Certified) → Remediation, with a target of **under 30 days** for FedRAMP's final assessment of a complete package. These changes are being consolidated into the **FedRAMP Consolidated Rules for 2026 (CR26)**, which NTC-0004 says FedRAMP expects to publish by the end of June 2026, valid through December 31, 2028. Existing listings are auto-mapped to the new designations during a transition period in which old and new labels are linked. Always confirm a specific service's current status on the official [FedRAMP Marketplace](https://marketplace.fedramp.gov/), since labels are in active transition. For the full process from preparation through continuous monitoring, see our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025). To understand where a listing sits and how agencies search it, read our [FedRAMP Marketplace explained](/blog/rev5/fedramp-marketplace-explained). And to budget the journey, see [how much FedRAMP costs](/blog/20x/fedramp-cost-2026) in 2026. ## Frequently asked questions ### Is "FedRAMP Certified" the same as "FedRAMP Authorized"? Yes. As of 2026, "FedRAMP Certified" is the official label that replaced "FedRAMP Authorized." A cloud service with a FedRAMP Certification is FedRAMP authorized for statutory and regulatory purposes, including agency reuse. The change in wording is meant to reduce confusion with an agency Authority to Operate. ### Does a FedRAMP Certification let any agency use my service immediately? No. A FedRAMP Certification provides a reusable package of security evidence, but each agency must still run its own NIST Risk Management Framework process and issue its own ATO before operating your service in its environment. Certification is the basis for that decision, not the decision itself. ### What happened to "FedRAMP Ready"? "FedRAMP Ready" is being retired. Providers early in the process now appear under a **Preparation** status on the FedRAMP Marketplace, reflecting that they are doing the essential work to manage security and privacy risks before formal assessment. ### Is there a "FedRAMP Validated" label for 20x? No. FedRAMP initially proposed a separate "FedRAMP Validated" designation for the 20x path in RFC-0020, but after public comment it decided in NTC-0004 to use the single **FedRAMP Certified** label for both Rev 5 and 20x. The Marketplace provides filters to distinguish the two paths. ### What are FedRAMP Certification Classes A, B, C, and D? They are the four assessment baselines, renamed in 2026. Class A is a new Rev 5 pilot baseline, Class B covers the legacy Li-SaaS and Low baselines, Class C covers Moderate, and Class D covers High. The names replaced the old "Low/Moderate/High level" language to avoid confusion with DoD Impact Levels. ### Who issues an ATO? An agency's Authorizing Official issues the ATO. This is a federal risk-acceptance decision under OMB Circular A-130 and the NIST Risk Management Framework. FedRAMP does not issue ATOs; it certifies that an authorization package is complete and reusable. ### When do the 2026 changes take effect? FedRAMP expects to publish the FedRAMP Consolidated Rules for 2026 (CR26) by the end of June 2026, valid through December 31, 2028, and is transitioning existing Marketplace listings to the new designations during that rollout. Check the official Marketplace for any given service's current status. ### How do I confirm a cloud service's current FedRAMP status? Use the official FedRAMP Marketplace at marketplace.fedramp.gov. It is the authoritative source for whether a service is in Preparation, under assessment, or FedRAMP Certified, and it provides filters to distinguish the Rev 5 and 20x paths. ## Sources - [FedRAMP RFC-0020 — FedRAMP Authorization Designations](https://www.fedramp.gov/rfcs/0020/) - [FedRAMP NTC-0004 — Initial Outcome from RFC-0020 (Authorization Designations)](https://www.fedramp.gov/notices/0004/) - [FedRAMP Requests for Comment (RFC index)](https://www.fedramp.gov/rfcs/) - [FedRAMP Marketplace](https://marketplace.fedramp.gov/) - [NIST Risk Management Framework — Categorize Step](https://csrc.nist.gov/Projects/risk-management/about-rmf/categorize-step) --- _Last updated: June 2026. Written by the Boundera team — the AI copilot for FedRAMP._ ### What FedRAMP 3PAO Assessors Look For (And How to Pass) - URL: https://boundera.io/blog/rev5/fedramp-3pao-assessors - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:28Z - Reading time: 9 minutes - Main question: What do FedRAMP 3PAO assessors look for, and how do you pass? - TL;DR: A FedRAMP 3PAO is the independent, FedRAMP-recognized firm that tests whether your cloud service actually implements its claimed controls. Assessors use NIST 800-53A's examine, interview, and test methods and expect all three to agree; you pass when every in-scope control is backed by current, specific, traceable evidence that matches your SSP. - Excerpt: What FedRAMP 3PAO assessors check, how they're accredited by A2LA, and what makes your evidence pass or fail - a practical 2026 guide. # What FedRAMP 3PAO Assessors Look For (And How to Pass) A FedRAMP 3PAO (Third-Party Assessment Organization) is the independent, FedRAMP-recognized firm that tests whether your cloud service actually implements the security controls you claim. Assessors look for one thing above all: evidence that what your documentation says is true in production, today. You pass when every in-scope control is backed by current, verifiable evidence that an outside expert can examine, test, and trace to a working mechanism — not a policy promise. **Key takeaways** - A 3PAO is accredited by the American Association for Laboratory Accreditation (A2LA) against ISO/IEC 17020 plus FedRAMP-specific knowledge requirements, with a favorable annual review and a full on-site reassessment every two years. - Assessors evaluate controls using three NIST 800-53A methods: **examine** (documents, configs), **interview** (your people), and **test** (live system behavior). All three must agree. - The 3PAO writes the **Security Assessment Plan (SAP)** before testing and the **Security Assessment Report (SAR)** after — the cloud service provider does not write these. - Evidence fails when it is stale, untraceable, inconsistent with the System Security Plan, or describes a planned state instead of the implemented state. - Under the 2026 consolidated rules, a single **"FedRAMP Certified"** label applies across four **Certification Classes (A, B, C, D)**; the 3PAO's job — independent verification — is unchanged. ## What is a 3PAO? A 3PAO is an independent assessment organization recognized by FedRAMP to perform the security assessments that support a FedRAMP authorization. The cloud service provider (CSP) builds and documents the system; the 3PAO independently verifies it. This separation is the structural reason FedRAMP authorizations are trusted across the federal government — the people testing the controls do not work for the company that built them. Concretely, a 3PAO does four things: 1. **Plans the assessment.** It produces the Security Assessment Plan (SAP), which defines scope, the controls to be tested, sampling, test procedures, and the assessment schedule. 2. **Executes testing.** It examines evidence, interviews staff, and tests the live system against the in-scope controls. 3. **Reports results.** It documents findings in the Security Assessment Report (SAR), including a risk picture and an authorization recommendation. 4. **Supports continuous monitoring.** After authorization, the 3PAO performs the recurring annual assessment and validates significant changes. If you want the full document chain that surrounds these deliverables, see our [FedRAMP documentation explained](/blog/rev5/fedramp-documentation-ssp-sap-sar-poam) breakdown of the SSP, SAP, SAR, and POA&M. ## How is a 3PAO accredited? A 3PAO earns and keeps its recognition through A2LA, not through a self-attestation. To become recognized, A2LA performs an initial assessment of the organization and recommends it to FedRAMP for approval. The bar is built on ISO/IEC 17020 — the international standard for bodies that perform inspections — layered with FedRAMP-specific knowledge requirements. Recognition is not permanent. To stay recognized, a 3PAO must pass a favorable A2LA annual review and a full on-site reassessment every two years. Assessment personnel must complete ongoing FedRAMP training each year. Organizations must also declare any foreign ownership, control, or influence (FOCI). One accreditation rule directly shapes who you can hire: under A2LA's R311 policy, a 3PAO that provided advisory or preparation services for a system generally cannot also perform the independent assessment of that same system for a defined period. The principle is simple — the firm that helped write your controls cannot be the one that independently grades them. | Accreditation element | What it means | Why it matters to you | | --- | --- | --- | | A2LA recognition | Independent accreditor vets and approves the 3PAO | Only a recognized 3PAO can perform a FedRAMP assessment | | ISO/IEC 17020 + FedRAMP knowledge | Quality system and competence standard | Sets the baseline for assessor rigor and consistency | | Annual review + biennial on-site | Ongoing oversight of the 3PAO | A recognized firm today may not be one tomorrow — verify current status | | Annual personnel training | Assessors stay current on FedRAMP rules | Your assessors should know the latest baselines and procedures | | R311 advisory separation | Advisor and assessor cannot be the same on one system | Plan your advisory and assessment vendors separately | > Source: [FedRAMP — How a company becomes a recognized 3PAO](https://help.fedramp.gov/hc/en-us/articles/27704465482139-How-does-a-company-become-a-FedRAMP-recognized-third-party-assessment-organization-3PAO-How-is-the-independence-and-quality-of-a-3PAO-validated) ## What do FedRAMP assessors actually check? Assessors check three things for every in-scope control, and they expect all three to tell the same story. This comes straight from the NIST 800-53A assessment methodology: - **Examine** — They read the artifacts: configuration exports, policies, screenshots with timestamps, scan results, system inventories, and the relevant SSP narrative. - **Interview** — They talk to the people who run the control: engineers, ISSOs, operations staff. They are checking whether the humans describe the control the same way the documents do. - **Test** — They observe or reproduce the control's behavior on the live system: triggering an alert, attempting an unauthorized action, confirming encryption settings, or watching a log flow into the SIEM. A finding is opened whenever those three diverge — when the policy says one thing, the engineer says another, and the system does a third. That divergence, not the absence of a fancy tool, is what most often costs CSPs an authorization recommendation. Below is a practical map of what assessors probe by control area. It is not exhaustive, but these are the areas where assessments most often succeed or stall. | Control area | What the assessor is verifying | Typical evidence requested | | --- | --- | --- | | Access Control (AC) | Least privilege, MFA on privileged access, account lifecycle | IAM role exports, MFA config, joiner/mover/leaver tickets | | Audit & Accountability (AU) | Logs are complete, centralized, retained, and reviewed | SIEM ingestion proof, retention settings, review records | | Configuration Management (CM) | Hardened baselines, change control, drift detection | Baseline definitions, change tickets, drift reports | | Identification & Auth (IA) | Strong authentication and validated cryptography | Crypto module evidence, authenticator settings | | Risk Assessment (RA) | Authenticated vulnerability scanning of all in-scope assets | Scan configs and results for OS, DB, web app, containers | | Incident Response (IR) | A tested plan with defined roles and reporting timelines | IRP, test/exercise records, sample tickets | | Contingency Planning (CP) | Backups and recovery are real and exercised | Backup configs, restore test results, plan test record | | System & Comms Protection (SC) | Encryption in transit, boundary protection, segmentation | TLS config, network diagrams, firewall rules | > Source: [NIST SP 800-53A — Assessing Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/a/r5/final) ## What makes evidence pass or fail? Evidence passes when it is current, specific, traceable, and consistent. It fails when it is any of: stale, generic, orphaned, or aspirational. Assessors are not trying to be difficult — they have to be able to defend every "satisfied" determination to an Authorizing Official, so anything they cannot independently verify becomes a finding. The single most common failure is the gap between the System Security Plan and reality. If your SSP describes a control implementation that the live system does not match, that is an immediate "other than satisfied" result. The fix starts long before assessment: keep your documentation aligned with your architecture as it changes, not the week before testing. Our [FedRAMP readiness assessment](/blog/rev5/fedramp-readiness-assessment) guide covers how to surface those gaps early. Here is the difference, control by control, in plain terms: | Dimension | Evidence that fails | Evidence that passes | | --- | --- | --- | | Freshness | Screenshot from eight months ago | Export dated within the assessment window | | Specificity | "We follow industry best practices" | Named tool, setting, value, and owner | | Traceability | A scan result with no asset mapping | Scan tied to an asset in the inventory and a control | | Consistency | SSP says daily review; logs show none | SSP, interview, and system all agree | | State | "We will implement MFA next quarter" | MFA enforced now; planned items live in the POA&M | A crucial nuance: an open weakness is not automatically a failure. FedRAMP expects findings. What matters is that each finding lands in the Plan of Action and Milestones (POA&M) with an owner, a risk level, and a realistic milestone date — and that you are not hiding it. Assessors and Authorizing Officials trust a complete, honest POA&M far more than a suspiciously clean one. ## How does a 3PAO assessment unfold? A first assessment follows a predictable arc, and knowing it helps you prepare evidence in the right order: 1. **Scoping and SAP.** The 3PAO confirms the authorization boundary against your SSP and writes the SAP. Review it carefully — if the boundary or control selection is wrong here, every downstream artifact inherits the error. 2. **Evidence collection.** You provide configuration exports, policies, scan results, and inventories. Expect requests to be specific and time-bound. 3. **Fieldwork.** The assessor runs examine/interview/test across the in-scope controls and performs or reviews vulnerability scans and, where required, penetration testing. 4. **Findings and SAR.** Results are documented in the SAR, each finding rated by risk, with an overall authorization recommendation. 5. **POA&M build-out.** Every SAR finding becomes a POA&M row with remediation owner and dates. The freeze window matters. During fieldwork, large changes to the in-scope system can invalidate testing, so plan your release calendar around the assessment, not against it. ## How do you choose a 3PAO? Choose a 3PAO that is currently recognized, experienced at your Certification Class, and structurally independent from whoever helped you prepare. Recognition status is verifiable — confirm it on the FedRAMP Marketplace rather than taking a vendor's word. Then weigh: - **Class and baseline experience.** Higher-assurance work is more specialized. A firm that has assessed many systems at your target class will move faster and surprise you less. - **Independence (R311).** If a firm advised on your SSP, it generally cannot assess that same system. Decide early whether a vendor is your advisor or your assessor — not both. - **Clarity of deliverables.** Get in writing what the 3PAO produces (SAP, SAR, scan analysis, pen test) versus what you must provide. - **References at your level.** Ask for references from CSPs at a similar class and architecture. For the end-to-end picture of where the 3PAO fits among sponsorship, packages, and authorization, see our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025). ## How does 2026 terminology change the 3PAO's role? The role does not change; the labels do. Under the FedRAMP Consolidated Rules for 2026, authorizations use a single **"FedRAMP Certified"** label, and systems map to four **Certification Classes** — Class A (a new pilot baseline), Class B (covering the prior LI-SaaS and Low baselines), Class C (the prior Moderate baseline), and Class D (the prior High baseline). FedRAMP is explicit that Certification Classes are not the same as a system's security categorization level — they describe the certification, not the data sensitivity. For assessors, the substance is constant: an independent, A2LA-recognized organization still examines, interviews, and tests your controls and still produces the assessment artifacts. If you have older materials referencing numbered "levels" or a "FedRAMP Validated" status, update them — those terms are retired under the 2026 rules. > Source: [FedRAMP — Certification Classes (2026 Consolidated Rules preview)](https://www.fedramp.gov/preview/2026/agencies/use/classes/) ## Frequently asked questions ### What does 3PAO stand for? 3PAO stands for Third-Party Assessment Organization. It is the independent, FedRAMP-recognized firm that assesses whether a cloud service provider has correctly implemented its required security controls, and that authors the Security Assessment Plan and Security Assessment Report. ### Is a 3PAO required for FedRAMP? Independent assessment by a FedRAMP-recognized 3PAO is the standard path for a FedRAMP authorization, because the program is built on third-party verification rather than self-attestation. Confirm the exact requirement for your Certification Class and path on fedramp.gov before you plan your timeline. ### Who accredits 3PAOs? The American Association for Laboratory Accreditation (A2LA) accredits 3PAOs against ISO/IEC 17020 plus FedRAMP-specific knowledge requirements. A2LA performs the initial assessment, a favorable annual review, and a full on-site reassessment every two years to maintain recognition. ### Can the same firm advise me and then assess me? Generally no. Under A2LA's R311 policy, a 3PAO that provided advisory or preparation services for a system cannot perform the independent assessment of that same system for a defined period. Plan your advisory and assessment vendors as separate engagements. ### What is the difference between the SAP and the SAR? The SAP (Security Assessment Plan) is written before testing and defines scope, controls, and procedures. The SAR (Security Assessment Report) is written after testing and documents what the assessor found, the risk of each finding, and an authorization recommendation. The 3PAO writes both; the CSP reviews and approves them. ### How do assessors decide whether a control is satisfied? They apply the NIST 800-53A methods — examine, interview, and test — and require the three to agree. If documentation, staff interviews, and live system behavior align and the evidence is current and traceable, the control is satisfied. Any meaningful divergence becomes a finding. ### Do open findings mean I failed the assessment? No. FedRAMP expects findings. Each one must be recorded in your POA&M with a risk level, owner, and realistic milestone. A complete, honest POA&M signals a healthy security program; a suspiciously empty one invites scrutiny. ### How long does a 3PAO assessment take? It varies by Certification Class, system complexity, and evidence readiness. The biggest lever you control is evidence quality — assessments stall most when documentation does not match the live system, forcing rework and re-testing. Aligning your SSP with reality before fieldwork is the fastest way to shorten the timeline. ## Sources - [FedRAMP — How a company becomes a recognized 3PAO (A2LA, ISO/IEC 17020)](https://help.fedramp.gov/hc/en-us/articles/27704465482139-How-does-a-company-become-a-FedRAMP-recognized-third-party-assessment-organization-3PAO-How-is-the-independence-and-quality-of-a-3PAO-validated) - [FedRAMP — What is a third-party assessment organization (3PAO)?](https://help.fedramp.gov/hc/en-us/articles/27704392312347-What-is-a-third-party-assessment-organization-3PAO) - [FedRAMP — Certification Classes (2026 Consolidated Rules preview)](https://www.fedramp.gov/preview/2026/agencies/use/classes/) - [FedRAMP — Certification (2026 Consolidated Rules preview)](https://www.fedramp.gov/preview/2026/certification/) - [NIST SP 800-53A Rev 5 — Assessing Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/a/r5/final) - [NIST SP 800-53 Rev 5 — Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) --- _Last updated: June 2026. Written by the Boundera team. Boundera is an AI copilot for FedRAMP that keeps your SSP, evidence, and POA&M aligned so 3PAO assessments go faster._ ### FedRAMP Readiness Assessment: What It Is and How to Pass - URL: https://boundera.io/blog/rev5/fedramp-readiness-assessment - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:27Z - Reading time: 8 minutes - Main question: What is a FedRAMP readiness assessment and how do you pass it? - TL;DR: A FedRAMP readiness assessment is a formal review by an accredited 3PAO that determines whether your cloud service is mature enough to succeed at a full FedRAMP assessment. It produces a Readiness Assessment Report (RAR). Readiness is optional but recommended; it is not the authorization itself, which requires a full assessment and an agency ATO to become FedRAMP Certified. - Excerpt: What a FedRAMP readiness assessment is, what's in the Readiness Assessment Report (RAR), the 3PAO's role, and how to prepare and pass in 2026. # FedRAMP Readiness Assessment: What It Is and How to Pass A FedRAMP readiness assessment is a formal review by an accredited Third Party Assessment Organization (3PAO) that determines whether your cloud service is mature enough to succeed at a full FedRAMP assessment. It produces a **Readiness Assessment Report (RAR)** — a 3PAO attestation that the system meets FedRAMP's federal-grade requirements and is likely to achieve authorization. Readiness is a dress rehearsal, not the authorization itself: passing it earns a marketplace listing and lowers your risk of an expensive failed assessment, but you still need a full assessment and an agency Authority to Operate (ATO) to be **FedRAMP Certified**. **Key takeaways** - A readiness assessment is performed by a **3PAO** and results in a **Readiness Assessment Report (RAR)** that FedRAMP reviews and approves. - Readiness is **optional but strongly recommended**; a clean RAR signals to agencies that your offering is real and de-risks the full assessment. - A readiness assessment is **not** the same as an internal **gap assessment** (your own pre-work) or a **pre-assessment** (an informal dry run) — readiness is the formal, 3PAO-signed step. - Under the 2026 framework (RFC-0020 / NTC-0004), a completed authorization carries the single label **FedRAMP Certified** with a **Certification Class (A–D)**; readiness is a milestone *toward* that, not a substitute for it. - The most common reasons CSPs fail readiness are an undefined authorization boundary, missing FIPS-validated encryption, and incomplete policies — all fixable before the 3PAO arrives. ## What is a FedRAMP readiness assessment? A FedRAMP readiness assessment is a structured evaluation, conducted by a FedRAMP-recognized **3PAO**, of whether a Cloud Service Offering (CSO) is prepared to undergo a full security assessment. The 3PAO reviews your architecture, documentation, and a focused set of capability requirements, then attests in a **Readiness Assessment Report (RAR)** that the system is — or is not — ready to pursue authorization. The point of readiness is to catch fatal problems early. A full assessment is expensive and time-consuming, and discovering a fundamental flaw (for example, an authorization boundary that excludes systems handling federal data, or encryption that is not FIPS-validated) *during* the full assessment can cost months and a second 3PAO engagement. Readiness surfaces those issues while they are still cheap to fix. Passing readiness — meaning FedRAMP reviews and approves your RAR — historically earned a **FedRAMP Ready** designation on the FedRAMP Marketplace. That designation tells agencies your offering has been independently vetted as capable, which makes you easier to sponsor. Under the 2026 changes confirmed in notice **NTC-0004**, the Marketplace lifecycle states are being renamed (the on-ramp listing state is being relabeled), but the underlying idea is unchanged: readiness is the credible, assessor-backed signal that you are worth an agency's time. > Source: [FedRAMP — Agency Authorization process](https://www.fedramp.gov/agencies/) ## What's in a Readiness Assessment Report (RAR)? The RAR is a 3PAO-authored document that walks through a defined set of FedRAMP capability requirements and records whether the CSO meets each one. It is narrower than a full Security Assessment Report (SAR): instead of testing every control, it confirms the system has the **foundational capabilities** that make a full assessment viable. A RAR typically covers: - **Authorization boundary** — a clear, accurate diagram of everything that processes, stores, or transmits federal data, and how data flows in and out. - **Federal mandates** — FIPS 140-2/3 validated cryptography, FIPS 199 categorization, digital identity (NIST SP 800-63) requirements, and other non-negotiables. - **Core security capabilities** — multi-factor authentication, encryption in transit and at rest, vulnerability scanning, audit logging, and incident response. - **3PAO attestation and recommendation** — the assessor's professional judgment on whether the CSO is ready, with any conditions or caveats noted. The 3PAO must base the RAR on observation and evidence, not just the provider's word. FedRAMP then reviews the RAR and decides whether to approve it. An approved RAR is a meaningful credential precisely because an independent, accredited assessor put their name on it. > Source: [NIST SP 800-53 Rev 5 — Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) ## What is the 3PAO's role in readiness? The 3PAO is the independent, accredited assessor at the center of readiness. Only a FedRAMP-recognized 3PAO can produce a RAR that FedRAMP will accept — a CSP cannot self-attest its way to a FedRAMP Ready designation. The 3PAO examines your environment and documentation, validates that the federal mandates and core capabilities are genuinely in place, and signs the report. There is an important independence rule worth planning around early: if a 3PAO (or its affiliates) helped you *build* your System Security Plan or stand up your controls, a **different, independent 3PAO** generally must perform the formal assessment. Mixing the advisory and assessment roles creates a conflict of interest that can invalidate the work. Decide up front whether a given firm is your advisor or your assessor. For a deeper look at how assessors evaluate evidence and where they push back, see [what 3PAO assessors look for](/blog/rev5/fedramp-3pao-assessors). ## Readiness assessment vs gap assessment vs pre-assessment? These three terms get used interchangeably, but they describe different things at different points in the journey. The cleanest way to distinguish them is *who performs them* and *what they produce*. | Activity | Who performs it | What it produces | When it happens | Formal? | | --- | --- | --- | --- | --- | | **Gap assessment** | You (or an advisory consultant) | An internal list of control and documentation gaps to close | Earliest — before you commit | No (internal) | | **Pre-assessment** | A 3PAO or advisor (informal) | An informal dry run / mock test of evidence and controls | After gaps are mostly closed | No (advisory) | | **Readiness assessment (RAR)** | A FedRAMP-recognized 3PAO | A formal **Readiness Assessment Report** FedRAMP reviews and approves | Just before the full assessment | **Yes (official)** | A **gap assessment** is your homework: you map your current state against the appropriate FedRAMP baseline, find what is missing, and build a remediation plan. It is internal and carries no official weight. A **pre-assessment** is an optional dry run — often a 3PAO or consultant kicking the tires to predict how the real thing will go. It is advisory, not a deliverable FedRAMP recognizes. A **readiness assessment** is the only one of the three that is formal and FedRAMP-recognized. It is performed by a 3PAO, produces the RAR, and (when approved) earns a Marketplace listing. Think of the sequence as: gap assessment → fix the gaps → optional pre-assessment → formal readiness (RAR) → full assessment → ATO. ## How is readiness different from authorization? Readiness confirms you are *prepared* to be assessed; authorization confirms you have *passed* assessment and an agency accepts the residual risk. They are different milestones with different deliverables and different consequences. | | Readiness assessment | Full authorization | | --- | --- | --- | | **Deliverable** | Readiness Assessment Report (RAR) | Full package: SSP, SAP, SAR, POA&M | | **Depth** | Foundational capabilities only | Every applicable control tested | | **Who decides** | FedRAMP reviews/approves the RAR | An agency Authorizing Official issues the ATO | | **Result** | Marketplace "Ready"-style listing | **FedRAMP Certified** + ATO | | **Required?** | Optional (recommended) | Required to operate with the agency | A FedRAMP Ready designation does **not** let an agency use your service. Only a full assessment and an agency-issued ATO get you to the single 2026 label, **FedRAMP Certified**, with its assigned **Certification Class (A–D)** — Class A (new pilot), B (the former LI-SaaS and Low baselines), C (Moderate), and D (High). FedRAMP deliberately uses these class labels rather than numbered "levels," and there is no separate "FedRAMP Validated" designation. For the full end-to-end path, see our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025). ## How do you prepare for and pass a readiness assessment? You pass readiness by closing your gaps *before* the 3PAO arrives — not by hoping the assessor overlooks them. The teams that sail through readiness treat it as the final check on work that is already done, not the moment they start the work. A practical checklist: | Area | What "ready" looks like | | --- | --- | | **Authorization boundary** | Defined, diagrammed, and accurate; all federal-data systems are inside it | | **Categorization** | FIPS 199 impact level set and justified | | **Encryption** | FIPS 140-2/3 validated modules at rest and in transit (TLS 1.2+) | | **Identity & access** | MFA on all privileged and remote access; least privilege documented | | **Vulnerability management** | OS, web app, DB, and container scanning covering 100% of the boundary | | **Logging** | Centralized log aggregation (SIEM) with all components reporting | | **Policies & plans** | Security policies, tested Incident Response Plan, tested Contingency Plan | | **Privacy & supply chain** | PII inventory and SR/PT control families addressed (Rev 5) | | **Evidence** | A single organized repository the 3PAO can navigate | Three failure modes account for most readiness setbacks: a **boundary that leaks** (some component handling federal data sits outside the documented boundary), **non-FIPS cryptography** lurking in a library or endpoint, and **policies that exist on paper but were never operationalized or tested**. Each is far cheaper to fix in week two of preparation than in the middle of a 3PAO engagement. This is where a copilot like **Boundera** earns its keep. Rather than scrambling to assemble evidence the week the 3PAO arrives, teams use Boundera to continuously pull configuration and scan data from AWS, Azure, and GCP, map it to the FedRAMP capabilities the RAR checks, and surface boundary or encryption gaps while they are still cheap to close. The result is a readiness assessment that confirms what you already know, instead of one that ambushes you. Because readiness fees and 3PAO time are a real line item, getting it right the first time also protects your budget — see our breakdown of [FedRAMP cost](/blog/20x/fedramp-cost-2026). ## Frequently asked questions ### Is a FedRAMP readiness assessment required? No. Readiness is optional. However, it is strongly recommended because an approved RAR earns a Marketplace listing, signals credibility to potential agency sponsors, and dramatically reduces the chance of a costly failed full assessment. Many CSPs treat it as a near-mandatory de-risking step. ### Who performs a FedRAMP readiness assessment? Only a FedRAMP-recognized **3PAO** (Third Party Assessment Organization) can perform a readiness assessment and produce a Readiness Assessment Report that FedRAMP will accept. You cannot self-attest readiness. The 3PAO must base its findings on observed evidence, not just provider statements. ### What is the difference between a RAR and an SSP? The **RAR** is a 3PAO's attestation that you are ready to be assessed, focused on foundational capabilities. The **SSP** (System Security Plan) is your own detailed description of how every applicable control is implemented, and it forms the core of the full authorization package. The RAR confirms you are ready; the SSP is what gets fully tested afterward. ### Does passing readiness make me FedRAMP Certified? No. A FedRAMP Ready-style designation means an accredited assessor judged you prepared — it does not authorize any agency to use your service. You become **FedRAMP Certified** only after a full assessment (SSP, SAP, SAR, POA&M) and an agency-issued ATO. Readiness is a milestone on the way, not the destination. ### How long does a readiness assessment take? The 3PAO fieldwork for readiness is typically shorter than a full assessment — often a few weeks — but the calendar time depends almost entirely on how prepared you are. Teams that close their gaps in advance move quickly; teams discovering boundary or encryption problems during readiness can add months of remediation before the RAR can be finalized. ### What's the difference between a readiness assessment and a gap assessment? A **gap assessment** is internal homework you (or an advisor) perform to find what is missing — it carries no official weight. A **readiness assessment** is a formal, 3PAO-conducted evaluation that produces a FedRAMP-reviewed RAR. Do the gap assessment first to fix problems; do the readiness assessment to get an independent, recognized sign-off. ### Can the same 3PAO do my readiness assessment and my full assessment? Often yes, provided that firm did not also build your documentation or controls. If a 3PAO acted as your advisor in standing up the SSP or controls, an independent 3PAO generally must perform the formal assessment to avoid a conflict of interest. Clarify each firm's role early. ### What are the four Certification Classes? Under the 2026 framework (RFC-0020 / NTC-0004), the four assessment baselines are **Certification Class A** (new pilot), **Class B** (the former LI-SaaS and Low baselines), **Class C** (Moderate), and **Class D** (High). They replace the old Low/Moderate/High tiers and are deliberately not numbered "levels," to avoid confusion with DoD Impact Levels. ## Sources - [FedRAMP — Agency Authorization process (fedramp.gov)](https://www.fedramp.gov/agencies/) - [FedRAMP — Documents and templates (fedramp.gov)](https://www.fedramp.gov/rev5/documents-templates/) - [NIST SP 800-53 Rev 5 — Security and Privacy Controls (csrc.nist.gov)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) - [NIST SP 800-63 — Digital Identity Guidelines (csrc.nist.gov)](https://csrc.nist.gov/pubs/sp/800/63/4/final) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP 20x Roadmap: Key Dates and Phases (2026) - URL: https://boundera.io/blog/20x/fedramp-20x-roadmap-2026 - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:26Z - Reading time: 9 minutes - Main question: What is the FedRAMP 20x roadmap and timeline for 2026? - TL;DR: As of June 2026, FedRAMP 20x has finished its Low (Phase 1) and Moderate (Phase 2) pilots and entered Phase 3, wide-scale adoption. FedRAMP is finalizing the Consolidated Rules for 2026 (CR26) by the end of June 2026, and the public submission pipeline for 20x Certifications is expected to open in FY26 Q4 (July-September 2026). A High-impact pilot is signaled for FY27. - Excerpt: Where FedRAMP 20x stands in 2026: completed Low and Moderate pilots, Phase 3 adoption, the CR26 rules, and what's next through FY27. # FedRAMP 20x Roadmap: Key Dates and Phases (2026) As of June 2026, FedRAMP 20x has finished its two pilot phases and entered **Phase 3, wide-scale adoption**. The Low pilot (Phase 1) and Moderate pilot (Phase 2) are both complete, FedRAMP is finalizing the **Consolidated Rules for 2026 (CR26)** by the end of June 2026, and the public submission pipeline for 20x Certifications is expected to open in FY26 Q4 (July–September 2026). A High-impact pilot is signaled for FY27. **Key takeaways** - FedRAMP 20x is in **Phase 3** as of April 2026; this is the move from pilots to a permanent, publicly available program. - **Phase 1** (Low pilot) ran April–September 2025 and produced an initial set of 20x Low authorizations from 26 public submissions. - **Phase 2** (Moderate pilot) ran November 2025–March 2026 and produced an initial set of 20x Moderate authorizations from 14 submissions. - The **Consolidated Rules for 2026 (CR26)** are due by the end of June 2026 and will remain valid through December 31, 2028. - Per **NTC-0004**, FedRAMP settled on a single label — **FedRAMP Certification** — with four assessment baselines named **Class A, B, C, and D**, not separate "Validated" designations or numbered levels. - The **20x submission pipeline** is expected to open in FY26 Q4, initially for Class A (Pilot), Class B (Low), and Class C (Moderate). ## What are the FedRAMP 20x phases? FedRAMP 20x is being delivered in five planned phases. Rather than launching a finished program all at once, FedRAMP designed each phase to test concepts publicly, gather real submissions, and adjust the rules before the next phase begins. The official phase plan as of June 2026 looks like this: | Phase | What it covers | Timeline | Status (June 2026) | | --- | --- | --- | --- | | Phase 1 | 20x Low pilot and proof of concept | FY25 Q3–Q4 (Apr–Sep 2025) | Completed | | Phase 2 | 20x Moderate pilot | FY26 Q1–Q2 (Nov 2025–Mar 2026) | Completed | | Phase 3 | Wide-scale adoption; formalize all 20x requirements | FY26 Q3–Q4 (Apr–Sep 2026) | Active | | Phase 4 | High-impact (Class D) pilot for cloud-native services | FY27 Q1–Q2 | Future | | Phase 5 | End of life for cloud-native Rev 5 Certifications | FY27 Q3–Q4 | Future | > Source: [FedRAMP 20x Phased Implementation — fedramp.gov/20x/phases](https://www.fedramp.gov/20x/phases/) The phases are sequential but overlapping in practice. FedRAMP continued reviewing Phase 1 submissions during Phase 2, and the rules that govern Phase 3 are still being finalized even though Phase 3 is already active. FedRAMP has been explicit that these timelines are estimated goals, not firm commitments, and that they shift based on real-world impact and the operating environment. ## What happened in the Phase 1 and Phase 2 pilots? The two pilots are the reason 20x exists in its current form — they tested whether automation-based validation could replace static, once-a-year manual assessments, and the answer was yes. **Phase 1 — the Low pilot (April–September 2025).** This pilot focused almost entirely on Key Security Indicators (KSIs) as a proof of concept for automated validation. Submissions were open to the public to maximize participation. FedRAMP received **26 complete submission packages** during a window that ran from May 30 to August 18, 2025, granted the first cohorts of pilot authorizations in late July 2025, and completed reviews of 13 submissions during the phase. The historical timeline records an initial **12 FedRAMP 20x Low pilot authorizations** from those 26 submissions, with more to follow as reviews continued. Phase 1 closed out at the end of FY25 alongside a broader milestone: FedRAMP completed 144 authorizations for the year and eliminated its long-standing authorization backlog. **Phase 2 — the Moderate pilot (November 2025–March 2026).** Phase 2 added the requirements needed for the FedRAMP Moderate baseline, testing the additional automated validation that a higher-sensitivity baseline demands. It started late — November 2025 — because of the longest lapse in federal appropriations on record, which paused FedRAMP's ability to meet with providers. The pilot completed in **March 2026** with an initial **8 FedRAMP 20x Moderate pilot authorizations** from 14 submissions, again with more reviews continuing afterward. One result from Phase 1 worth flagging for any provider planning a 20x path: no participants were interested in reusing existing external framework assessments such as SOC 2, and the largest single category of submissions was GRC tooling — a direct consequence of 20x allowing program authorizations without an agency sponsor. > Source: [Phase 1 Recap](https://www.fedramp.gov/20x/phases/1/) and [FedRAMP 20x Historical Timeline](https://www.fedramp.gov/20x/timeline/) ## What is the timeline for 2026? 2026 is the year FedRAMP 20x stops being a pilot and becomes a program any qualifying provider can pursue. The near-term calendar is dense, and most of the load-bearing dates fall in the second and third quarters. | Milestone | Date | What it means | | --- | --- | --- | | RFC-0020 (Authorization Designations) closed | February 19, 2026 | Public comment ended on how FedRAMP authorizations would be labeled | | NTC-0004 published | February 25, 2026 | FedRAMP announced the final designation decisions (see below) | | Phase 2 Moderate pilot completed | March 2026 | Initial 20x Moderate authorizations issued; CR26 preparation begins | | Phase 3 begins | April 2026 | Wide-scale adoption phase starts; pilots officially over | | Consolidated Rules for 2026 (CR26) finalized | End of June 2026 | All 20x requirements formalized; rules valid through Dec 31, 2028 | | 20x submission pipeline opens | FY26 Q4 (Jul–Sep 2026) | Public can submit for 20x Certification (Class A, B, and C) | > Source: [NTC-0004 — Initial Outcome from RFC-0020](https://www.fedramp.gov/notices/0004/) and [FedRAMP 20x Phase 3](https://www.fedramp.gov/20x/phases/3/) The single most important shift to understand from this stretch is the naming outcome in **NTC-0004**. RFC-0020 originally floated separate designations and additional baselines, but after public comment FedRAMP simplified everything: - There is **one official label**: a cloud service is **FedRAMP Certified**, full stop. FedRAMP decided against separate "FedRAMP Validated" branding for 20x versus Rev 5, on the grounds that two labels would confuse procurement. The two paths will instead be distinguished by **filters in the FedRAMP Marketplace**. - FedRAMP **declined to use "levels" or numbers** for the baselines, to avoid confusion with the DoD Impact Level (IL) system. Instead, the four assessment baselines are labeled **Class A, B, C, and D**. - For Rev 5: Class A is a new pilot baseline, Class B covers the current LiSaaS and Low baselines, Class C covers Moderate, and Class D covers High. 20x baselines will align to the same Class structure inside CR26. A FedRAMP Certification is not, by itself, an agency authorization to operate. The Class label describes the depth and type of information a provider supplies for assessment — not a guarantee that the service is appropriate for a given agency at a given FIPS 199 category. Agencies still make their own risk decisions using the certification package. ## What is coming next after Phase 3? After Phase 3 formalizes the program, two future phases extend 20x to higher-sensitivity systems and begin sunsetting the legacy path for cloud-native services. **Phase 4 — High-impact (Class D) pilot, FY27 Q1–Q2.** FedRAMP plans to pilot a 20x path for High-impact, cloud-native services (the Class D baseline) while wide-scale adoption continues. This phase is also where FedRAMP intends to determine the future of certification for platform services that are not cloud-native — a meaningful open question for providers whose architecture doesn't fit the automation-first model. **Phase 5 — end of life for cloud-native Rev 5 Certifications, FY27 Q3–Q4.** At the end of this phase, FedRAMP plans to **stop accepting new Rev 5 Certifications for cloud-native services** and to publish a clear path and timeline for migrating existing cloud-native Rev 5 offerings to 20x. FedRAMP has signaled this transition is likely to include multi-year deadlines, so existing Rev 5 authorizations are not at near-term risk — but the long-run direction for new cloud-native services is unambiguously 20x. For a side-by-side of how the two models differ in practice, see our breakdown of [FedRAMP 20x vs Rev 5](/blog/20x/fedramp-20x-vs-rev5). If you are weighing the investment, our [FedRAMP 20x cost](/blog/20x/fedramp-20x-cost) analysis covers what changes when assessment shifts from documentation to continuous validation. And because both paths now resolve to a single "FedRAMP Certified" label differentiated only by marketplace filters, our guide to the [FedRAMP Marketplace](/blog/rev5/fedramp-marketplace-explained) explains how buyers will actually tell the paths apart. ## How should providers read this roadmap right now? The practical message for a provider in mid-2026 is that the window between "pilot" and "open program" is short, and preparation done now compounds. The pilots proved that the bottleneck in 20x is not paperwork — it is whether your engineering telemetry can continuously prove KSI outcomes. Providers that wait for CR26 to publish before building inventory, evidence pipelines, and automated validation will start Phase 3 behind providers that treated the pilots as a preview. Three concrete moves hold up regardless of how the remaining dates shift: - **Map your boundary and inventory now.** Minimum Assessment Scope is the same input whether you pursue Class B or Class C, and a clean inventory is the foundation every KSI sits on. - **Instrument KSI evidence as machine-readable, not screenshot-based.** The pilots rewarded providers who could generate validation from live system data and penalized those relying on static narratives. - **Decide your Class early.** Class B (Low) and Class C (Moderate) open first in FY26 Q4; Class D (High) is not piloted until FY27. If you need High, plan around the later timeline rather than assuming day-one availability. ## Frequently asked questions ### What phase is FedRAMP 20x in as of June 2026? FedRAMP 20x is in **Phase 3 — wide-scale adoption**, which began in April 2026. Both pilot phases (Low and Moderate) are complete, and FedRAMP is finalizing the Consolidated Rules for 2026 by the end of June 2026. ### When can companies actually submit for a 20x Certification? The public submission pipeline for FedRAMP 20x is expected to open in **FY26 Q4 (July–September 2026)**, initially for Class A (Pilot), Class B (Low), and Class C (Moderate) Certifications. This date is an estimated goal and may shift. ### What are the Consolidated Rules for 2026 (CR26)? CR26 is the document that formalizes all FedRAMP 20x requirements for cloud service providers. FedRAMP plans to finalize it by the **end of June 2026**, and the rules will remain valid through **December 31, 2028**. ### Did FedRAMP adopt numbered levels or "FedRAMP Validated" designations? No. Per **NTC-0004** (published February 25, 2026), FedRAMP chose a single label — **FedRAMP Certification / FedRAMP Certified** — and declined to use numbered levels or a separate "FedRAMP Validated" designation. The four assessment baselines are labeled **Class A, B, C, and D**, and the 20x versus Rev 5 distinction will be shown through Marketplace filters instead of separate labels. ### What is the difference between the Class A, B, C, and D baselines? The Class label describes the depth and type of information a provider supplies for assessment. For Rev 5: Class A is a new pilot baseline, Class B covers the current LiSaaS and Low baselines, Class C covers Moderate, and Class D covers High. 20x baselines align to the same structure under CR26. ### When will FedRAMP 20x support High-impact systems? A High-impact (Class D) pilot for cloud-native services is planned for **Phase 4, FY27 Q1–Q2**. As of June 2026, 20x is opening first for the Class A, B, and C baselines. ### Is Rev 5 going away? Not immediately. FedRAMP plans to stop accepting **new Rev 5 Certifications for cloud-native services** at the end of **Phase 5 (FY27 Q3–Q4)** and to publish a migration path with what it has signaled will likely be multi-year deadlines. Existing Rev 5 authorizations are not at near-term risk. ## Sources - [FedRAMP 20x Overview — fedramp.gov/20x](https://www.fedramp.gov/20x/) - [FedRAMP 20x Phased Implementation — fedramp.gov/20x/phases](https://www.fedramp.gov/20x/phases/) - [FedRAMP 20x Phase 1 Recap — fedramp.gov/20x/phases/1](https://www.fedramp.gov/20x/phases/1/) - [FedRAMP 20x Phase 3 — fedramp.gov/20x/phases/3](https://www.fedramp.gov/20x/phases/3/) - [FedRAMP 20x Historical Timeline — fedramp.gov/20x/timeline](https://www.fedramp.gov/20x/timeline/) - [RFC-0020 FedRAMP Authorization Designations — fedramp.gov/rfcs/0020](https://www.fedramp.gov/rfcs/0020/) - [NTC-0004 Initial Outcome from RFC-0020 — fedramp.gov/notices/0004](https://www.fedramp.gov/notices/0004/) --- _Last updated: June 2026. Written by the Boundera team._ ### OSCAL for FedRAMP: What It Is and Why It Matters - URL: https://boundera.io/blog/20x/oscal-for-fedramp-guide - Program: FedRAMP 20x - Category: Automation - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:25Z - Reading time: 8 minutes - Main question: What is OSCAL and why does FedRAMP use it? - TL;DR: OSCAL (Open Security Controls Assessment Language) is a NIST-led, machine-readable standard for expressing security controls, system security plans, and assessment results in XML, JSON, and YAML instead of Word and Excel. FedRAMP uses OSCAL so authorization packages can be validated, exchanged, and assessed by software, and it is the data format underpinning the automation goals of FedRAMP 20x. - Excerpt: OSCAL is NIST's machine-readable standard for security controls and authorization packages. Here's what it is, its models, and how FedRAMP and 20x use it. # OSCAL for FedRAMP: What It Is and Why It Matters OSCAL (the Open Security Controls Assessment Language) is a NIST-led, machine-readable standard for expressing security controls, system security plans, and assessment results in structured XML, JSON, and YAML instead of Word and Excel documents. FedRAMP uses OSCAL so authorization packages can be validated, exchanged, and assessed by software rather than read line by line, and it is the data format underpinning the automation goals of FedRAMP 20x. **Key takeaways** - OSCAL stands for Open Security Controls Assessment Language and is maintained by NIST in collaboration with industry, with formats available in XML, JSON, and YAML. - OSCAL is organized into three layers, control, implementation, and assessment, that together hold seven core models, from the control catalog up to the POA&M. - FedRAMP publishes OSCAL baselines and templates (SSP, SAP, SAR, POA&M) and validation rules in the GSA `fedramp-automation` repository, built on NIST OSCAL 1.0.4. - FedRAMP 20x leans on OSCAL and Key Security Indicators (KSIs) to make authorization data continuously machine-readable, but the file format alone does not equal 20x readiness. - OSCAL is the data standard; it does not collect evidence, define your boundary, or prove a control is working. Those still require live operational systems. ## What is OSCAL? OSCAL is a set of open, machine-readable formats for representing security and compliance information so that tools, not just humans, can process it. NIST describes it as an initiative to "modernize and automate the processes of security and compliance," providing formats in XML, JSON, and YAML that streamline control-based risk assessments and can reduce audit durations from months to minutes. The core idea is a shift from document-centric compliance to data-centric compliance. A traditional System Security Plan is a 300-plus page Word file that a human assessor reads and a human author maintains. The same information expressed in OSCAL is a structured data file with defined fields, identifiers, and relationships, so a validator can check that required content exists, a tool can generate a human-readable version on demand, and two versions of a package can be compared automatically. OSCAL does not invent new security requirements. It is a neutral encoding for the controls, baselines, and assessment artifacts that already exist in frameworks like NIST SP 800-53. The value is in expression and exchange: the same control implementation, written once in OSCAL, can be read by any conforming tool without re-keying. ## What are the OSCAL models? OSCAL is organized as a stack of layers, where each higher layer builds on and references the layer beneath it. NIST defines three layers, control, implementation, and assessment, that contain the core authorization-package models. The table below lists each model and what it represents. | OSCAL model | Layer | What it represents | | --- | --- | --- | | Catalog | Control | A set of controls (for example, NIST SP 800-53) expressed in machine-readable form. The catalog is the basis for every other model; controls used elsewhere must first be defined here. | | Profile | Control | A selection and tailoring of catalog controls into a baseline or overlay, with full traceability back to the source catalog. FedRAMP Low, Moderate, and High baselines are published as OSCAL profiles. | | Component Definition | Implementation | A reusable description of a single component (software, service, policy, or process) and how its configuration satisfies controls, so SSP tooling can pre-populate implementations. | | System Security Plan (SSP) | Implementation | The security implementation of a specific system against a chosen baseline. The machine-readable SSP can be imported into tools and transformed back into a human-readable document. | | Assessment Plan (SAP) | Assessment | How and when an assessment will be performed, including scope and the activities to be conducted. | | Assessment Results (SAR) | Assessment | The findings produced by assessment activities, including when it was performed, the scope, evidence collected, and results. Supports both snapshot and continuous assessment. | | Plan of Action and Milestones (POA&M) | Assessment | The set of findings that the system owner must remediate, tracked from a periodic or continuous assessment. | > Source: [NIST OSCAL, Layers and Models](https://pages.nist.gov/OSCAL/learn/concepts/layer/) A defining property of this stack is native traceability. Because each model imports the artifacts beneath it, you can trace a single finding in a POA&M back through the SAR, the SSP, the profile that selected the control, and the catalog where the control was originally defined. That end-to-end chain is what makes OSCAL packages auditable by machine rather than by manual cross-reference. NIST also maintains a Control Mapping model in the control layer for relating controls across different frameworks, though the seven models above are the ones that make up a FedRAMP authorization package. ## Why does FedRAMP use OSCAL? FedRAMP uses OSCAL because a federal authorization package is enormous, repetitive, and exchanged among many parties, the cloud service provider, the third-party assessment organization (3PAO), and the authorizing agency, and a structured format removes the manual labor and error that come with passing documents between them. The FedRAMP Program Management Office publishes its OSCAL work in the GSA `fedramp-automation` repository. That work includes the FedRAMP Rev 5 baselines for High, Moderate, Low, and LI-SaaS as OSCAL profiles; OSCAL templates for the SSP, SAP, SAR, and POA&M in XML, JSON, and YAML; a FedRAMP OSCAL Registry that defines FedRAMP-specific extensions and accepted values; and a set of Schematron validation rules that check whether a submitted OSCAL package actually conforms to FedRAMP requirements. FedRAMP's OSCAL artifacts are built on NIST OSCAL 1.0.4. The practical payoff is validation before submission. Instead of a 3PAO or agency discovering a missing field deep in review, a CSP can run its OSCAL package through FedRAMP's published rules and catch structural gaps up front. The same data also flows: a control implementation written once in the SSP can be referenced by the SAP and SAR without re-entry, and the POA&M ties directly to the findings that produced it. If you are moving an existing package into this format, our companion walkthrough on how to [convert your SSP to OSCAL](/blog/20x/ssp-to-oscal-guide) covers the hands-on steps; this post stays on the concepts. ## How does OSCAL relate to FedRAMP 20x and KSIs? FedRAMP 20x is built on the assumption that authorization data is machine-readable and continuously current, and OSCAL is the format that carries that data. Where the legacy Rev 5 process treats OSCAL as a better way to submit a largely static package, 20x treats structured, automatable data as the operating model itself. The bridge between OSCAL and 20x is the Key Security Indicator. KSIs are FedRAMP-defined, validatable statements about a system's security posture, things that can be checked with evidence rather than described in narrative prose. The aim is to replace long control write-ups with indicators a tool can evaluate and report on, and OSCAL's assessment-layer models (assessment results and POA&M) are the natural place for that machine-readable evidence to live. Teams pursuing this path typically want to [automate KSI evidence](/blog/20x/fedramp-20x-ksi-evidence-automation) collection directly from their cloud and identity systems so the OSCAL package reflects the real running state. This is also where a common misconception needs correcting. Being able to export OSCAL is not the same as being 20x-ready. OSCAL is a schema; it can carry current, validated evidence, but it cannot create that evidence on its own. If the inventory is stale and the KSI evidence is collected manually, an OSCAL export is just old compliance data in a modern wrapper. We unpack this fully in [why OSCAL alone is not 20x readiness](/blog/20x/oscal-alone-is-not-fedramp-20x-readiness). The short version: OSCAL is necessary plumbing for 20x, but the readiness comes from the live evidence operations behind it. ## What OSCAL does not do OSCAL is a data standard, so it is worth being precise about its limits. OSCAL does not define your authorization boundary, discover in-scope resources, validate cloud configurations, prove that multi-factor authentication is enforced, confirm logging coverage, or keep your inventory current. Those depend on evidence sources, validation logic, and human ownership, not on the file format. In other words, OSCAL is how you express the truth about a system. It does not produce that truth. A correctly structured, fully valid OSCAL SSP can still describe a system inaccurately if the data feeding it is wrong. The format guarantees consistency and machine-readability, not accuracy. This distinction is the single most useful thing to keep in mind when a tool or vendor claims OSCAL support: the question is never just "can it emit OSCAL?" but "where does the data come from, and is it current?" ## Frequently asked questions ### What does OSCAL stand for? OSCAL stands for Open Security Controls Assessment Language. It is a NIST-led initiative, developed with industry, that provides open, machine-readable formats (XML, JSON, and YAML) for representing security controls and compliance information. ### Is OSCAL required for FedRAMP? FedRAMP has invested heavily in OSCAL and publishes its baselines, templates, and validation rules in OSCAL, and machine-readable packages are central to the direction of FedRAMP 20x. The degree to which OSCAL submission is mandatory depends on the specific path and current FedRAMP guidance, so confirm the requirement for your authorization route against fedramp.gov rather than assuming. Either way, OSCAL is the format FedRAMP's automation is built around. ### What are the seven OSCAL models? The seven core OSCAL models are the Catalog and Profile (control layer); the Component Definition and System Security Plan (implementation layer); and the Assessment Plan, Assessment Results, and Plan of Action and Milestones (assessment layer). Each higher model references the ones beneath it, giving end-to-end traceability from a finding back to the originating control. ### What is the difference between OSCAL and NIST SP 800-53? NIST SP 800-53 is the catalog of security and privacy controls, the actual requirements. OSCAL is the machine-readable language used to express those controls, plus the baselines, system plans, and assessment artifacts that reference them. NIST publishes SP 800-53 Rev 5 itself in OSCAL format, so the two are complementary: 800-53 is the content, OSCAL is the encoding. ### Does OSCAL replace the SSP? No. OSCAL changes the SSP's format, not its purpose. The System Security Plan is one of the OSCAL implementation-layer models, so the SSP still exists, it is just expressed as structured data that tools can validate and that can be transformed back into a human-readable document on demand. ### What formats does OSCAL support? OSCAL content is available in XML, JSON, and YAML. Because YAML is a superset of JSON, the same JSON schema can often validate YAML as well, and NIST provides converters between XML and JSON for each model. ### Does exporting OSCAL make me FedRAMP 20x-ready? No. OSCAL is the format that carries 20x data, but 20x readiness depends on current, validated evidence behind Key Security Indicators, continuous validation, and authorization data sharing. An OSCAL export built from stale or manual data is modern in format but not 20x-ready in substance. ## Sources - [NIST OSCAL, Open Security Controls Assessment Language](https://pages.nist.gov/OSCAL/) - [NIST OSCAL, Layers and Models](https://pages.nist.gov/OSCAL/learn/concepts/layer/) - [NIST OSCAL, Model Overview](https://pages.nist.gov/OSCAL/learn/concepts/layer/overview/) - [GSA FedRAMP Automation repository](https://github.com/GSA/fedramp-automation) - [FedRAMP, Using the FedRAMP OSCAL Resources and Templates](https://www.fedramp.gov/using-the-fedramp-oscal-resources-and-templates/) - [NIST SP 800-53 Rev 5 (CSRC)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) --- _Last updated: June 2026. Written by the Boundera team._ ### How to Convert Your SSP to OSCAL: A Step-by-Step Guide - URL: https://boundera.io/blog/20x/ssp-to-oscal-guide - Program: FedRAMP 20x - Category: Automation - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:24Z - Reading time: 9 minutes - Main question: How do you convert an SSP to OSCAL? - TL;DR: To convert a Word/Excel SSP to OSCAL, map your content into the six parts of the NIST OSCAL SSP model (metadata, import-profile, system-characteristics, system-implementation, control-implementation, back-matter), start from FedRAMP's OSCAL SSP template and the matching baseline, move each control narrative into an implemented-requirement, then validate against FedRAMP's published Schematron constraints until clean. - Excerpt: A hands-on guide to converting an existing Word/Excel SSP into OSCAL: map the six-section OSCAL SSP model, use FedRAMP templates, and validate against FedRAMP constraints. # How to Convert Your SSP to OSCAL: A Step-by-Step Guide To convert a Word/Excel System Security Plan (SSP) into OSCAL, you map your existing content into the six parts of the [NIST OSCAL SSP model](https://pages.nist.gov/OSCAL/learn/concepts/layer/implementation/ssp/) — metadata, import-profile, system-characteristics, system-implementation, control-implementation, and back-matter — then validate the result against FedRAMP's published constraints. The practical workflow is: start from FedRAMP's OSCAL SSP template, point it at the correct OSCAL baseline (Low, Moderate, High, or LI-SaaS), move each control narrative into an `implemented-requirement`, and run the FedRAMP validation rules until the file is clean. OSCAL is a structured data format, not prose, so the real work is re-expressing what you already wrote — not rewriting it. **Key takeaways** - OSCAL is NIST's machine-readable standard (XML, JSON, or YAML) for security documentation; FedRAMP publishes OSCAL **templates, a registry of extensions, and validation rules** on top of it. - A FedRAMP OSCAL SSP has **six top-level sections**; the bulk of conversion effort lands in `control-implementation`, where each control narrative becomes an `implemented-requirement`. - FedRAMP's OSCAL work targets a specific **NIST OSCAL version** (the published FedRAMP release was built on OSCAL 1.0.4), so always match your tooling to the version FedRAMP supports. - You do not start from a blank file: begin from the **FedRAMP OSCAL SSP template** and the matching **OSCAL baseline** so identifiers and extensions line up. - Validation is non-negotiable — a file that opens fine in a text editor can still fail FedRAMP's **Schematron constraint checks**. ## What does "convert an SSP to OSCAL" actually mean? It means re-expressing the same facts your Word SSP and Excel workbooks already contain as structured OSCAL data, so that machines — assessors' tools, the FedRAMP review pipeline, and your own automation — can read and validate them directly. A traditional SSP is a narrative document: headings, tables, and paragraphs meant for a human reader. OSCAL is the opposite. It stores the same information as typed, addressable data: the authorization boundary, information types and impact level, the system inventory, responsible roles, control parameters, and a per-control description of how each requirement is satisfied. Because every element has a stable identifier, an OSCAL SSP can be diffed, queried, and checked against rules in ways a Word file never can. If you want the conceptual background first — what OSCAL is, why NIST built it, and how the layers fit together — read our companion explainer, [OSCAL for FedRAMP explained](/blog/20x/oscal-for-fedramp-guide). This post assumes you already have an SSP and want to move it into OSCAL. | | Word/Excel SSP | OSCAL SSP | | --- | --- | --- | | Format | `.docx` narrative + `.xlsx` workbooks | XML, JSON, or YAML data | | Audience | Human readers | Tools, validators, and humans (via rendering) | | Control content | Prose paragraphs in Appendix A | `implemented-requirement` per control, addressable to the statement level | | Identifiers | Section numbers, manual cross-refs | UUIDs and tokens with referential integrity | | Validation | Manual review / checklists | Automated schema + FedRAMP constraint checks | | Updates | Track-changes, version copies | New document UUID + `last-modified` timestamp on every change | > Source: [NIST OSCAL — System Security Plan (SSP) Model](https://pages.nist.gov/OSCAL/learn/concepts/layer/implementation/ssp/) ## What is the OSCAL SSP model structure? The OSCAL SSP model is organized into six top-level sections, in this order. Knowing them is the map for the entire conversion. 1. **`metadata`** — document title, version, publication date, OSCAL version, plus the roles, parties (people, teams, organizations), and locations referenced elsewhere in the file. Required in every OSCAL model. 2. **`import-profile`** — a pointer to the control baseline your system claims, expressed as an OSCAL profile. For FedRAMP this is the Low, Moderate, High, or Tailored LI-SaaS baseline. 3. **`system-characteristics`** — the system's name, description, authorization boundary, information types, security categorization/impact level, and status. 4. **`system-implementation`** — how the system is deployed: users and their roles, components, interconnections, services, and the system inventory. 5. **`control-implementation`** — one `implemented-requirement` per control in the baseline, describing how the control is satisfied. Satisfaction can be described for the whole system or attributed to specific components, down to an individual control statement, and can carry parameter values, responsible roles, implementation status, and control origination. 6. **`back-matter`** — attachments, citations, and embedded resources (diagrams, policies, and other referenced files). Two NIST rules matter from the start: every time the file's content changes, you must generate a **new document-level UUID** on the root element and update the **`last-modified`** timestamp in metadata. Those two values are how tools detect that a file has actually changed. > Source: [NIST OSCAL — SSP Model Overview](https://pages.nist.gov/OSCAL/learn/concepts/layer/implementation/ssp/) ## How do you convert an SSP to OSCAL, step by step? ### Step 1 — Understand the target and pick your OSCAL version Before touching your content, decide which OSCAL version you're producing and confirm it matches what FedRAMP supports. FedRAMP's published OSCAL release was built on **NIST OSCAL 1.0.4**, and the program only supports data at or above the minimum version it tags. Producing a file against the wrong version is the easiest way to fail review before anyone reads a single narrative. Read the NIST SSP model reference and FedRAMP's guidance so you know exactly what the finished file must contain. ### Step 2 — Choose your tooling You have three broad options, and most teams combine them: - **Start from FedRAMP's OSCAL templates.** FedRAMP publishes pre-populated SSP, SAP, SAR, and POA&M template files in XML, JSON, and YAML, seeded with FedRAMP extensions, defined identifiers, and conformity tags. This is the recommended starting point because it bakes in the FedRAMP-specific structure you'd otherwise have to reverse-engineer. - **Use NIST and open-source tooling.** NIST provides XML-to-JSON and JSON-to-XML converters and schema files, so you can author in whichever serialization you prefer and convert losslessly. - **Generate from system data.** Rather than hand-typing thousands of lines, derive the OSCAL SSP programmatically from your inventory, identity provider, and cloud configuration. This is where automation earns its keep (more below). Pick one serialization to author in — JSON and YAML are friendlier to hand-edit than XML — knowing you can convert with NIST's official converters at any time. ### Step 3 — Map system characteristics and implementation Move the descriptive parts of your SSP first, because they're the most mechanical: - From your SSP front matter and identification tables → populate `system-characteristics` (system name, description, boundary, information types, impact level). - From your inventory workbook and architecture sections → populate `system-implementation` (components, users/roles, interconnections, services, inventory items). - From your points-of-contact tables → populate `metadata` roles and parties, then reference those party UUIDs wherever a responsible role is named. Get identifiers right here. Roles, parties, and components you define in this step are referenced by UUID throughout `control-implementation`, and FedRAMP's validators check that every reference resolves. ### Step 4 — Map your control implementations This is the heart of the conversion and where the most time goes. For each control in your baseline: - Create an `implemented-requirement` keyed to the control's ID (e.g., `ac-2`). - Move the corresponding Appendix A narrative into the implementation description. - Attribute satisfaction to the right components using `by-component`, rather than describing everything at the system level, when a specific component does the work. - Set the **implementation status**, **control origination** (system-specific, inherited, hybrid, etc.), and any **parameter values** the baseline expects. - Where the baseline defines named statements within a control, attach narratives to the matching `statement` so detail lands at the right granularity. A clean, specific narrative converts well; a vague one ("we follow industry best practices") converts into a vague OSCAL field that an assessor still can't test. Conversion is a good moment to tighten weak narratives, not just relocate them. ### Step 5 — Wire up the baseline (import-profile) and back-matter Set `import-profile` to the correct **FedRAMP OSCAL baseline** — Low, Moderate, High, or Tailored LI-SaaS — published in the FedRAMP automation repository. This is what lets a validator confirm that every `control-id` and `param-id` you reference actually exists in the baseline. Then move diagrams, policies, and other attachments into `back-matter` as resources, and link to them by UUID from the relevant sections. ### Step 6 — Validate against FedRAMP constraints Schema-valid is not the same as FedRAMP-valid. FedRAMP publishes its rules as **Schematron** validations (the FedRAMP ASAP rule set) in the GSA automation repository, with browsable rule documentation and an in-browser validator. Run your file through two layers: 1. **NIST schema validation** — confirms the file is well-formed OSCAL for the SSP model. 2. **FedRAMP constraint validation** — confirms FedRAMP-specific requirements: extensions present, required identifiers used, references resolving, accepted values respected. Fix every error, regenerate the document UUID and `last-modified` on each change, and repeat until clean. ### Step 7 — Export, package, and submit Once validation passes, produce the serialization FedRAMP expects (you can convert between XML and JSON with NIST's converters), package the OSCAL SSP with its companion artifacts, and submit through your authorization path. Because the package is now data, downstream artifacts — the SAP, SAR, and POA&M — can reference the same identifiers, keeping the whole package internally consistent. If you need a refresher on how those documents relate, see [FedRAMP documentation explained](/blog/rev5/fedramp-documentation-ssp-sap-sar-poam). ## What are the most common SSP-to-OSCAL pitfalls? The failures we see most often are mechanical, not conceptual: - **Wrong OSCAL version.** Authoring against a NIST version FedRAMP doesn't support, then discovering it at submission time. - **Starting from a blank file.** Skipping the FedRAMP template means re-inventing extensions and identifiers, and missing FedRAMP-specific fields entirely. - **Broken references.** A `component-uuid`, `party-uuid`, or `role-id` that points at nothing. The schema may pass; FedRAMP's constraint checks will not. - **System-level dumping.** Putting every narrative at the system level instead of attributing it to the component that implements it, which loses the traceability OSCAL exists to provide. - **Forgetting the UUID/`last-modified` discipline.** Editing content without minting a new document UUID and timestamp, which breaks change-detection for any tool consuming the file. - **Treating conversion as a one-time event.** An OSCAL SSP that drifts from the running system is just a Word SSP with angle brackets. ## How does automation generate and maintain an OSCAL SSP? The most durable way to "convert" an SSP is to stop treating it as a document you transcribe and start treating it as a **report generated from your system's actual state**. This is the angle Boundera is built around. Much of an OSCAL SSP is derivable from sources you already operate: your cloud accounts describe the boundary and inventory, your identity provider describes users and roles, and your configuration management describes how technical controls are implemented. An automation layer can read those sources and emit the `system-characteristics`, `system-implementation`, and large parts of `control-implementation` directly — with consistent UUIDs and FedRAMP extensions already in place — then run the FedRAMP validations on every build. The payoff isn't the first conversion; it's the second hundred. When your system changes, the OSCAL SSP regenerates from current data instead of being hand-patched, the document UUID and `last-modified` update automatically, and your narratives stay aligned with reality through continuous monitoring. The same source-of-truth approach extends to evidence — see how teams [automate KSI evidence](/blog/20x/fedramp-20x-ksi-evidence-automation) for FedRAMP 20x. ## Frequently asked questions ### Do I have to rewrite my SSP from scratch to use OSCAL? No. OSCAL conversion is about re-expressing the facts your existing SSP already contains as structured data, not authoring new content. You map your boundary, inventory, roles, and control narratives into the OSCAL SSP model's six sections. It is, however, a good opportunity to tighten vague narratives, since weak prose converts into weak OSCAL. ### What format should I author my OSCAL SSP in — XML, JSON, or YAML? Author in whichever serialization your tooling and team prefer; NIST provides official converters between XML and JSON, so the choice isn't permanent. JSON and YAML are generally easier to read and hand-edit than XML. FedRAMP publishes its templates in all three formats. ### Which OSCAL version does FedRAMP require? Match your tooling to the version FedRAMP supports — its published OSCAL release was built on NIST OSCAL 1.0.4, and FedRAMP only supports data at or above its tagged minimum version. Because NIST issues periodic syntax updates, always check the current NIST OSCAL release notes alongside FedRAMP's guidance before you build. ### How do I validate a FedRAMP OSCAL SSP? Validate in two layers. First, check the file against NIST's OSCAL SSP schema to confirm it's well-formed OSCAL. Second, run FedRAMP's Schematron constraint rules (the FedRAMP ASAP rule set in the GSA automation repository) to confirm FedRAMP-specific requirements — extensions, identifiers, references, and accepted values. The repository includes browsable rule documentation and an in-browser validator. ### Where do FedRAMP's OSCAL templates and validation rules live? In the GSA `fedramp-automation` repository on GitHub, which hosts the FedRAMP OSCAL SSP/SAP/SAR/POA&M templates, the FedRAMP OSCAL Registry of extensions and identifiers, the OSCAL baselines, and the Schematron validation rules. Note that this repository was archived in mid-2025, so always confirm you're working from the version and guidance FedRAMP currently points to. ### Can I generate an OSCAL SSP automatically instead of building it by hand? Yes. Because much of the SSP is derivable from system data — cloud inventory, identity provider, configuration management — automation can generate the bulk of `system-characteristics`, `system-implementation`, and `control-implementation` and keep them current as the system changes. That turns the OSCAL SSP from a document you maintain into a report you regenerate. ### Does converting to OSCAL change my FedRAMP designation? No. OSCAL is a format for your documentation, not a different authorization. Your designation is the same single label — **FedRAMP Certified** — whether you take the Rev 5 or 20x path, and OSCAL simply makes the package machine-readable for review and continuous monitoring. ## Sources - [NIST OSCAL — System Security Plan (SSP) Model](https://pages.nist.gov/OSCAL/learn/concepts/layer/implementation/ssp/) - [NIST OSCAL — Layers and Models overview](https://pages.nist.gov/OSCAL/learn/concepts/layer/) - [GSA FedRAMP Automation repository (templates, registry, baselines, validation rules)](https://github.com/GSA/fedramp-automation) - [FedRAMP — Using the FedRAMP OSCAL Resources and Templates](https://www.fedramp.gov/using-the-fedramp-oscal-resources-and-templates/) --- _Last updated: June 2026. Written by the Boundera team._ ### KSIs vs the SSP: What FedRAMP 20x Changes About Documentation - URL: https://boundera.io/blog/20x/ksi-vs-ssp - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:23Z - Reading time: 9 minutes - Main question: What is the difference between the FedRAMP Rev 5 SSP and the FedRAMP 20x KSI approach? - TL;DR: Under Rev 5, the SSP is a large narrative document describing how a system implements the NIST 800-53 baseline control by control. FedRAMP 20x replaces most of that prose with Key Security Indicators (11 themes) backed by machine-readable and human-readable evidence that is continuously and automatically validated rather than assessed once a year. - Excerpt: FedRAMP 20x replaces the Rev 5 SSP's control-by-control narrative with KSI evidence packages that are machine-readable and continuously validated. Here's what changes. # KSIs vs the SSP: What FedRAMP 20x Changes About Documentation Under traditional FedRAMP Rev 5, the System Security Plan (SSP) is a large narrative document that describes, control by control, how your system implements the NIST SP 800-53 baseline. FedRAMP 20x replaces most of that prose with Key Security Indicators (KSIs): defined security goals that you satisfy with machine-readable, human-readable evidence packages that are continuously and automatically validated rather than written up once a year. The SSP does not vanish overnight, but its center of gravity shifts from "describe what you do" to "prove what is true, right now." **Key takeaways** - The Rev 5 SSP is a long written narrative covering the full NIST 800-53 baseline (Low ~156, Moderate 323, High 410 controls). FedRAMP 20x is "designed for automated demonstration of secure configurations and practices" instead of "extensive written narratives describing static security decisions" (fedramp.gov). - FedRAMP 20x organizes requirements around Key Security Indicators (KSIs) spanning **11 themes**, each backed by an evidence package that is both machine-readable and human-readable. - KSI evidence is **persistently validated** — checked continuously and automatically — rather than assessed at a single point in time once per year. - Under the 2026 rules (RFC-0020 / NTC-0004), all FedRAMP authorizations use a single **FedRAMP Certified** label, with four **Certification Classes (A–D)** in place of Low/Moderate/High. There is no separate "FedRAMP Validated" designation. - FedRAMP 20x Phase 1 pilot participants reached authorization in **less than two months**, versus the years that a traditional Rev 5 SSP-driven authorization typically takes (fedramp.gov). ## What is the difference between an SSP and KSIs? An SSP and a set of KSIs answer the same underlying question — "is this cloud service secure enough?" — in fundamentally different ways. The **SSP (System Security Plan)** is the centerpiece of a Rev 5 authorization package. It is a structured Word document, often hundreds of pages, that identifies the system, draws the authorization boundary, categorizes data, and then walks through every applicable NIST SP 800-53 control with a written narrative explaining how that control is implemented. A 3PAO reads those narratives, tests a sample, and reports findings in a Security Assessment Report. The artifact is static between assessments: it describes the design and implementation as of a point in time. **Key Security Indicators (KSIs)** flip the model. Instead of a control-by-control essay, FedRAMP 20x defines a set of security goals grouped into 11 themes (for example, identity, configuration, monitoring, and incident response). For each KSI, the provider submits an evidence package that is simultaneously **machine-readable** (so tools and reviewers can parse and validate it programmatically) and **human-readable** (so a person can understand the claim). Critically, those packages are **persistently validated**: the status, progress, and outcomes are, in FedRAMP's words, "automatically enforced and validated without human input whenever possible to enable continuous review and enforce ground truth." The practical difference: an SSP narrative says a control *should* happen; a KSI evidence package shows, on an ongoing basis, that it *is* happening — and flags what will automatically occur if it stops. > Source: [FedRAMP 20x Overview — fedramp.gov/20x](https://www.fedramp.gov/20x/) ## How does the SSP compare to the KSI approach? | Dimension | SSP (FedRAMP Rev 5) | KSI approach (FedRAMP 20x) | | --- | --- | --- | | Primary artifact | Large narrative document (System Security Plan) | Key Security Indicator evidence packages across 11 themes | | Format | Word/PDF prose plus appendices and workbooks | Machine-readable **and** human-readable evidence | | Typical length | Hundreds of pages of control narratives | Structured evidence keyed to each KSI, not page count | | Basis | NIST SP 800-53 Rev 5 baseline (Low ~156, Moderate 323, High 410 controls) | Security goals/outcomes validated by KSIs | | How it is assessed | 3PAO reads narratives, tests a sample, writes a SAR | Automated validation of secure configurations and practices | | Cadence of truth | Point-in-time; refreshed at annual assessment | Persistent, continuous, automatic validation | | Update model | Manual edits to documents when the system changes | Evidence updates as the live environment changes | | Resulting label (2026) | FedRAMP Certified (via the Rev 5 path) | FedRAMP Certified (via the 20x path) | | Agency sponsor | Typically required in advance | Not required; FedRAMP reviews requests directly | | Time to authorization | Often years of preparation | Pilot participants authorized in under two months | > Source: [FedRAMP Rev5 vs FedRAMP 20x — fedramp.gov/20x](https://www.fedramp.gov/20x/) and [Rev 5 Documents & Templates — fedramp.gov](https://www.fedramp.gov/rev5/documents-templates/) ## Does FedRAMP 20x still require an SSP? FedRAMP 20x does not lean on the traditional 500-page SSP as the engine of assessment. The program is explicitly "designed for automated demonstration of secure configurations and practices," which is a deliberate move away from Rev 5's "extensive written narratives describing static security decisions." That said, "no narrative essay" is not the same as "no documentation." A 20x submission still needs to define the cloud service offering, its boundary, and the data it handles so reviewers understand what is being validated. What changes is the *form* and the *weight* of that documentation: the burden moves from prose that humans must read and trust to evidence that systems can validate continuously. Foundational context still exists; it just stops being the thing an assessor spends most of their time reading. If you are pursuing a Rev 5 agency authorization today, the SSP is still required, still uses the official FedRAMP PMO template, and still drives the SAP and SAR. If you are pursuing a 20x path, you should plan your program around producing and maintaining KSI evidence — not around writing and re-writing a giant SSP. ## Why is FedRAMP moving away from the 500-page SSP? FedRAMP's own framing is blunt: Rev 5 was "designed for extensive written narratives describing static security decisions," and that model has well-known failure modes. Narratives drift from reality the moment the system changes. Point-in-time assessments tell you a system was compliant in the past, not that it is secure today. And the sheer volume of writing pushes authorization timelines into years. The 20x rationale rests on a few principles published on fedramp.gov: - **Accountability over box-checking.** "No provider should worry about preparing for a point-in-time audit since the security of the cloud service is continuously and automatically enforced, monitored, and reported." - **Automatic validation.** "A policy that a thing must happen means nothing compared to a continuous report showing how that thing is happening over time and what will automatically occur if it stops." - **Speed and adoption.** The Phase 1 pilot demonstrated that a KSI-based approach "could successfully demonstrate security posture in near real time to replace static yearly manual assessments and narratives while improving confidence and overall security," with some providers authorized in under two months. In short, the SSP optimized for a reviewer reading a document. KSIs optimize for evidence a machine can keep checking — which is a better fit for cloud systems that change daily. > Source: [FedRAMP 20x Phase 1 Recap — fedramp.gov](https://www.fedramp.gov/20x/phases/1/) ## What does a KSI evidence package look like in practice? This is where the SSP-versus-KSI distinction becomes concrete, and where the engineering work actually lives. Take a single security goal — say, enforcing strong, phishing-resistant authentication. Under Rev 5, you would write a narrative for the relevant IA-family controls describing your MFA configuration, then your 3PAO would sample accounts at assessment time and write up the result. Under 20x, that goal is expressed as a KSI, and you produce an evidence package that: - **Is machine-readable** — structured data pulled directly from your identity provider and cloud configuration, so a validator can confirm the state programmatically rather than reading a paragraph about it. - **Is human-readable** — accompanied by a clear, plain-language statement of the claim and how the evidence supports it, so a reviewer (or an Authorizing Official) can understand it without parsing raw JSON. - **Is persistently validated** — wired so the check runs continuously. If a privileged account drops MFA, the evidence reflects that change instead of waiting for next year's assessment. At Boundera, this is the core of how we help teams move from Rev 5 habits to 20x. The hard part is rarely writing the claim; it is connecting the claim to live sources (cloud provider APIs, identity platforms, scanners) so each KSI is backed by current, validatable evidence rather than a screenshot taken once. For a deeper walkthrough, see our guide on how to [automate KSI evidence](/blog/20x/fedramp-20x-ksi-evidence-automation), and for the full taxonomy of indicators, the [FedRAMP 20x KSI guide](/blog/20x/fedramp-20x-ksi-guide). ## Which approach is right for you? The honest answer in mid-2026 is: it depends on your path, your timeline, and the impact level you need. Choose or stay with the **Rev 5 SSP** path if: - You are already deep in an agency authorization, or your sponsoring agency requires it. - You need a High baseline today, where the Rev 5 process is the established, proven route. - Your buyers specifically ask for a FedRAMP Certification via the Rev 5 path. Lean toward the **20x KSI** path if: - You want speed and have engineering capacity to wire up continuous evidence. - You do not have an agency sponsor lined up — 20x lets FedRAMP review your request directly. - Your security program already runs on automation, IaC, and live telemetry, so producing machine-readable evidence is a natural extension of how you operate. For most teams the realistic move is to build the KSI evidence pipeline regardless of path, because continuous, validatable evidence makes a Rev 5 authorization easier *and* positions you for 20x. The two are not opposites so much as two points on a trajectory away from static paperwork. For a fuller breakdown of the documents involved in the traditional path, see our [FedRAMP documentation explained](/blog/rev5/fedramp-documentation-ssp-sap-sar-poam) guide. ## Frequently asked questions ### Is the SSP being eliminated by FedRAMP 20x? Not exactly. FedRAMP 20x is "designed for automated demonstration of secure configurations and practices" rather than the "extensive written narratives" of Rev 5, so the giant control-by-control SSP narrative is no longer the engine of assessment. You still need to define your service, boundary, and data, but the documentation burden shifts heavily toward machine-readable, continuously validated KSI evidence. ### How many KSIs are there? FedRAMP 20x organizes Key Security Indicators into 11 themes. Each KSI is backed by an evidence package that is both machine-readable and human-readable and is persistently validated rather than checked once a year. ### What does "machine-readable and human-readable" evidence mean? It means the same KSI evidence serves two audiences at once: structured data that automated validators and reviewers can parse and check programmatically, and a clear written claim that a person can understand without reading raw data. This dual format is what enables continuous, automatic validation. ### Are FedRAMP's 2026 designations called "Certification Classes A–D"? Partly. Under the 2026 rules, every authorization carries the single label **FedRAMP Certified**, and the four assessment baselines are named **Certification Class A, B, C, and D** (replacing Low/Moderate/High). FedRAMP deliberately avoided numbered "levels" to prevent confusion with DoD Impact Levels, and it declined a separate "FedRAMP Validated" label for the 20x path. ### Is FedRAMP 20x faster than the Rev 5 SSP process? In the Phase 1 pilot, yes. FedRAMP reports that pilot participants received authorization in less than two months from start, compared with the years of preparation typically required for a traditional Rev 5 authorization built around the SSP. ### Do I still need a 3PAO under FedRAMP 20x? Independent assessment remains part of FedRAMP, but its nature changes. FedRAMP noted that the assessment process "would need to change entirely from the traditional control-by-control minimum-bar audit approach" toward evaluating the effectiveness of security decisions and validating evidence, rather than reading and questioning narratives line by line. ### Can I reuse my existing Rev 5 SSP for a 20x submission? Your underlying security implementations carry over, but the SSP narrative itself is not the deliverable a 20x submission is built on. You will need to express your security posture as KSI evidence packages. The good news is that the work of connecting controls to live evidence — which Boundera helps automate — benefits both paths. ## Sources - [FedRAMP 20x Overview — fedramp.gov/20x](https://www.fedramp.gov/20x/) - [FedRAMP 20x Phase 1 Recap — fedramp.gov/20x/phases/1](https://www.fedramp.gov/20x/phases/1/) - [Rev 5 Documents & Templates (including the Baseline SSP) — fedramp.gov](https://www.fedramp.gov/rev5/documents-templates/) - [NIST SP 800-53 Rev 5 — csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP 20x KSI Validation: How Often and in What Format - URL: https://boundera.io/blog/20x/fedramp-20x-ksi-validation - Program: FedRAMP 20x - Category: Automation - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:22Z - Reading time: 7 minutes - Main question: How often must FedRAMP 20x KSI evidence be validated, and in what format? - TL;DR: FedRAMP 20x requires machine-based KSI validation at least every 7 days at Low and every 3 days at Moderate, and non-machine-based validation at least every 3 months. Every result must be both machine-readable and human-readable and regenerable on demand; screenshots and static dumps are not acceptable as the system of record. - Excerpt: FedRAMP 20x KSI validation cadence and format: machine-based every 7 days (Low) / 3 days (Moderate), non-machine every 3 months, evidence machine- and human-readable. # FedRAMP 20x KSI Validation: How Often and in What Format Under FedRAMP 20x, Key Security Indicator (KSI) evidence must be validated on a fixed cadence: machine-based information resources at least once every 7 days at Low and at least once every 3 days at Moderate, and non-machine-based validations at least once every 3 months. Every validation result must be both machine-readable and human-readable and regenerable on demand. Static screenshots and configuration dumps are not acceptable as the system of record. **Key takeaways** - Machine-based KSI validation runs at least every **7 days at Low** and at least every **3 days at Moderate** (FedRAMP requirement PVA-CSX-PMV). - Non-machine-based validation must complete at least **once every 3 months** (PVA-CSX-NMV). - 20x **High** is expected to be more frequent than Moderate, but FedRAMP has not yet finalized the cadence. - Evidence must be **machine-readable and human-readable** and regenerable on demand; screenshots and static dumps cannot be the system of record (PVA-TPX-STE). - A failed validation, or a broken validation pipeline, is treated as a **vulnerability** under Vulnerability Detection and Response (PVA-CSX-FAV). ## How often must KSI evidence be validated? FedRAMP 20x sets validation frequency by two factors: whether the information resource is machine-based or non-machine-based, and the impact level of the cloud service offering. For machine-based information resources, providers MUST complete the validation processes for their Key Security Indicators at least once every 7 days at Low and at least once every 3 days at Moderate. This requirement is identified as PVA-CSX-PMV in the FedRAMP 20x Persistent Validation and Assessment process. For non-machine-based information resources, providers MUST complete the validation processes at least once every 3 months. This is requirement PVA-CSX-NMV. These are floors, not targets. The word "least" is doing real work: a provider whose engineering workflow already validates configuration on every deployment is free to validate far more often, and most mature 20x programs will. The cadence numbers exist so that no in-scope resource ever goes longer than the stated window without a fresh, current validation result. | Resource type | Low | Moderate | High | | --- | --- | --- | --- | | Machine-based information resources | At least every 7 days | At least every 3 days | More frequent than Moderate; cadence not yet finalized | | Non-machine-based information resources | At least every 3 months | At least every 3 months | At least every 3 months (High specifics not yet finalized) | > Source: [FedRAMP 20x Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) (PVA-CSX-PMV, PVA-CSX-NMV) The "machine vs non-machine" split is the part teams most often get wrong, so it is worth defining precisely. ## What's the difference between machine-based and non-machine validations? A machine-based information resource is one whose state can be checked programmatically. Cloud resources, identity provider configuration, network rules, encryption settings, and pipeline controls all fall here, because a script or API call can read the current state and compare it to the expected state. These resources carry the tight cadence, every 7 days at Low and every 3 days at Moderate, precisely because automation makes frequent checking cheap. A non-machine-based information resource is one validated through a human process rather than an automated query. Examples include a tabletop exercise, a policy review, a signed acknowledgment of security training, or a documented approval that has no machine-queryable equivalent. These run on the quarterly cadence: at least once every 3 months. The distinction is not about importance. A non-machine validation is not "lower priority" evidence. It still needs a defined process, an owner, a recency requirement, and a result that ties back to a specific KSI. The cadence is longer only because the underlying activity is human and cannot be polled on a three-day loop. One practical consequence: most real KSIs are validated by a mix of both methods. FedRAMP's KSI implementation summary requirement (KSI-CSX-SUM) explicitly asks providers to document the machine-based processes and their persistent cycle, and the non-machine-based processes and their persistent cycle, separately, for each KSI. If a KSI has both, both cadences apply to their respective parts. ## What format does FedRAMP require for KSI evidence? FedRAMP 20x requires validation evidence that is both machine-readable and human-readable, and that can be regenerated on demand from the live system. The point is that evidence reflects the current state of the offering, not a frozen snapshot from an earlier moment. This rules out a long-standing compliance habit. Assessors MUST NOT rely on screenshots, configuration dumps, or other static output as evidence, except when they are evaluating the accuracy and reliability of the process that generates such artifacts (requirement PVA-TPX-STE). In other words, a screenshot can illustrate how a control looks, but it cannot be the authoritative record that the control is in place right now. A strong KSI validation result is a structured object, not a picture. It should be queryable by a machine and readable by a human reviewer, and it should carry enough context to stand on its own: - The KSI or assertion being checked - The information resource or process in scope - The source system the evidence came from - The expected condition (the pass/fail criteria) - The actual observed condition - The pass or fail result - The timestamp of the validation - A reference back to the underlying evidence - The owner or remediation path if the check fails "Encryption is enabled" is not a validation. A validation says which storage resources were checked, what encryption setting was required, what the cloud API actually returned, when the check ran, and which resources, if any, failed. That object is machine-readable enough to feed a dashboard and human-readable enough for an assessor to follow. Because the evidence must be regenerable on demand, the system of record is the pipeline, not a folder of exports. If an assessor asks for current state, the answer is to run the validation again and produce a fresh, timestamped result, not to retrieve a file someone saved last month. This is the operational heart of [persistent validation](/blog/20x/fedramp-20x-persistent-validation), and it is why most 20x teams move quickly to [automate KSI evidence collection](/blog/20x/fedramp-20x-ksi-evidence-automation) rather than assemble packages by hand. ## What happens when a validation fails? A failed validation is a vulnerability. FedRAMP is explicit: providers MUST treat issues detected during persistent validation, and failures of the persistent validation process itself, as vulnerabilities, then handle them under the FedRAMP Vulnerability Detection and Response process (requirement PVA-CSX-FAV). Two distinct failure modes both count: 1. **A failed check** — the validation ran and returned a non-compliant result. For example, a storage resource that should be encrypted is not. This is a finding about the offering's security state. 2. **A broken pipeline** — the validation could not run, ran incompletely, or stopped producing current results. A scanner that silently fails, a credential that expired, or a job that skipped half the in-scope resources all fall here. The gap in coverage is itself the vulnerability. This second case is what makes 20x validation different from a scheduled scan. Under traditional continuous monitoring, a scan that did not run was an operational nuisance. Under 20x, a validation that did not run leaves an in-scope resource without current evidence, and that absence is treated as a vulnerability to be detected, tracked, and remediated. It is not enough to be compliant when checked; the checking itself has to keep working. The practical implication is that your validation cadence and your pipeline health are part of the same obligation. Missing a 3-day Moderate window is not a paperwork lapse. It produces stale evidence, and stale evidence on an in-scope resource is a finding. ## How assessors evaluate validation cadence and format Assessors do not just confirm that a validation result says "pass." They verify the underlying processes, both machine-based and non-machine-based, that produce those results. That includes the effectiveness, completeness, and integrity of the automated checks, the same for the human processes, and whether the processes actually cover every consolidated information resource in scope (requirement PVA-TPX-UNP). To survive that review, a provider should be able to show, for each KSI: - The pass/fail criteria and how they were defined - Which information resources are covered and how missing ones are detected - The machine cadence and the non-machine cadence, documented per KSI - How evidence is protected from tampering and how stale evidence is flagged - How failed checks and failed pipelines are routed and remediated If the process behind a result cannot be explained, the result is hard to trust, regardless of how clean the output looks. For the full set of themes these checks map to, see our [FedRAMP 20x KSI guide](/blog/20x/fedramp-20x-ksi-guide), which covers all eleven KSI themes from Authorization by FedRAMP through Supply Chain Risk. ## Frequently asked questions ### How often must FedRAMP 20x KSI evidence be validated? Machine-based information resources must be validated at least once every 7 days at Low and at least once every 3 days at Moderate. Non-machine-based information resources must be validated at least once every 3 months. These are minimums under FedRAMP requirements PVA-CSX-PMV and PVA-CSX-NMV; more frequent validation is allowed and common. ### What is the validation cadence for FedRAMP 20x High? FedRAMP states that High is expected to require more frequent machine-based validation than Moderate, but the specific cadence has not yet been finalized in current 20x guidance. Providers planning for High should expect a window shorter than the 3-day Moderate requirement. ### Are screenshots acceptable as KSI evidence? No, not as the system of record. Assessors must not rely on screenshots, configuration dumps, or other static output as evidence, except when they are evaluating the reliability of the process that generates those artifacts (PVA-TPX-STE). Evidence must be machine-readable and human-readable and regenerable on demand from the live system. ### What does "machine-readable and human-readable" mean in practice? It means each validation result is a structured object a machine can query (for dashboards, alerting, and authorization data) and a person can read and follow (for assessor review). A single screenshot is human-readable but not machine-readable; a raw JSON blob with no context is machine-readable but hard for a reviewer to interpret. 20x evidence has to be both. ### What is the difference between a machine-based and a non-machine-based information resource? A machine-based resource has a state that can be checked programmatically, such as cloud configuration, identity settings, or network rules, and carries the 7-day or 3-day cadence. A non-machine-based resource is validated through a human process, such as a tabletop exercise or a policy review, and carries the quarterly cadence. Many KSIs involve both, and each part follows its own cadence. ### What happens if a KSI validation fails or a pipeline breaks? Both are treated as vulnerabilities. A failed check and a failed or broken validation pipeline must be handled under the FedRAMP Vulnerability Detection and Response process (PVA-CSX-FAV). A pipeline that stops producing current results leaves in-scope resources without fresh evidence, and that gap is itself the finding. ### Does the cadence reset if I validate more often than required? The cadence is a maximum interval, not a fixed schedule. Validating more frequently than every 7 days at Low or every 3 days at Moderate is fully compliant and encouraged. The requirement is only that no in-scope resource ever exceeds the stated window without a current validation result. ## Sources - [FedRAMP 20x Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) (PVA-CSX-PMV, PVA-CSX-NMV, PVA-CSX-FAV, PVA-TPX-STE, PVA-TPX-UNP) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) (KSI-CSX-SUM and the eleven KSI themes) - [FedRAMP 20x Vulnerability Detection and Response](https://www.fedramp.gov/docs/20x/vulnerability-detection-and-response/) --- _Last updated: June 2026. Written by the Boundera team._ ### The Hidden Costs of FedRAMP (That Wreck Budgets) - URL: https://boundera.io/blog/20x/fedramp-hidden-costs - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:21Z - Reading time: 9 minutes - Main question: What are the hidden costs of FedRAMP? - TL;DR: The hidden costs of FedRAMP are the ones not on a 3PAO quote: internal engineering and remediation time, dedicated compliance staff like an ISSO, year-over-year continuous monitoring labor, the annual 3PAO reassessment, GRC and security tooling, and scope creep. In Boundera's analysis these soft costs routinely match or exceed the headline assessment fee, and they recur every year. Moderate programs typically run $500K-$1.5M initial and $200K-$500K/year (complex lifecycles $2M-$5M); High runs $1M-$3M+ initial and $500K-$1M/year. - Excerpt: The FedRAMP costs teams under-budget: internal engineering, ISSO/security staff, year-over-year ConMon labor, the annual 3PAO reassessment, tooling, and scope creep. # The Hidden Costs of FedRAMP (That Wreck Budgets) The hidden costs of FedRAMP are the ones that never appear on a 3PAO quote: internal engineering and remediation time, dedicated compliance staff like an ISSO, year-over-year continuous monitoring (ConMon) labor, the annual 3PAO reassessment, GRC and security tooling, and scope creep that quietly expands your boundary. In Boundera's analysis of FedRAMP engagements, these soft costs routinely match or exceed the headline assessment fee, and they keep billing every year after you reach authorization. **Key takeaways** - The visible 3PAO fee ($50K–$400K+, with a Readiness Assessment Report adding $30K–$80K) is often the *smaller* half of the bill. - Internal staffing dominates the true cost: a FedRAMP Moderate program typically runs $500K–$1.5M initial and $200K–$500K per year, with complex lifecycles reaching $2M–$5M — and most of that is labor, not vendor invoices. - Continuous monitoring is a permanent line item: monthly vulnerability scans, POA&M upkeep, and an annual assessment never stop. - The annual 3PAO reassessment is a recurring fee, not a one-time event — budget for it every year. - Scope creep and significant-change re-assessments are the most common reasons a "fixed" budget blows up. - GAO has documented that real FedRAMP costs are poorly tracked and vary widely, which is exactly why teams under-budget them. ## What costs do CSPs underestimate the most? The costs CSPs underestimate are almost never the ones on a vendor's price sheet. Teams budget carefully for the 3PAO assessment and the documentation package, then get blindsided by everything that surrounds those line items. The Government Accountability Office studied this directly. In its 2024 review of the program, GAO found that FedRAMP cost estimates "ranged anywhere from tens of thousands to millions of dollars," that data on *actual* costs was limited, and that agencies and providers used inconsistent methods to calculate them. When the government itself cannot pin down what FedRAMP costs, it is no surprise that a CSP's first budget is usually too low. Here are the categories that consistently get under-funded: - **Internal engineering time** spent hardening infrastructure, refactoring identity and network architecture, and building logging and vulnerability-management pipelines. - **Remediation labor** to close every gap a readiness assessment or 3PAO uncovers — work that competes with your product roadmap. - **Dedicated compliance staff**, including an ISSO (Information System Security Officer) and often new security hires whose salaries recur indefinitely. - **Continuous monitoring labor**, the single largest *recurring* hidden cost. - **The annual 3PAO reassessment**, a fee that returns every year. - **GRC and security tooling** — scanners, SIEM, log analytics, and a compliance platform — with renewing license costs. - **Boundary and scope creep** that pulls more components into assessment than originally planned. - **Opportunity cost** of a slow timeline: revenue deferred while federal deals wait on your ATO. ## What are the hidden costs of FedRAMP, by category? The table below maps the costs that wreck budgets. The dollar ranges reflect Boundera's analysis across impact levels; the "one-time vs recurring" column is what teams most often get wrong. | Hidden cost category | What it is | Typical impact / range | One-time vs recurring | | --- | --- | --- | --- | | Internal engineering & remediation | Eng hours to harden the environment and close control gaps | Often the largest single cost; a major share of $500K–$1.5M (Moderate) initial | One-time per cycle, but reappears after major changes | | Dedicated compliance staff (ISSO, security hires) | Salaried roles to own the program and respond to assessors | $150K–$400K+ per year, per role, fully loaded | Recurring | | Continuous monitoring (ConMon) labor | Monthly scans, POA&M upkeep, monthly reporting, deviation requests | A large share of $200K–$500K/yr (Moderate); $500K–$1M/yr (High) | Recurring | | Annual 3PAO reassessment | Required independent annual assessment of a control subset | Part of the $50K–$400K+ 3PAO range, **every year** | Recurring | | Readiness Assessment Report (RAR) | Optional pre-assessment to validate readiness | $30K–$80K | One-time | | GRC & security tooling | Scanners, SIEM, log analytics, compliance platform licenses | Tens of thousands to low six figures per year | Recurring | | Boundary / scope creep | Components added to the boundary mid-engagement | Can add 25–100%+ to assessment and ConMon scope | One-time + recurring | | Significant-change re-assessment | Extra 3PAO testing triggered by major architecture changes | Variable; a partial reassessment fee per event | Event-driven recurring | | Opportunity cost of a slow timeline | Federal revenue deferred while authorization is pending | Often the largest *unbudgeted* cost of all | One-time per deal cycle | > Source: Boundera analysis of FedRAMP engagements. Cost-variability and tracking findings: [GAO-24-106591](https://www.gao.gov/products/gao-24-106591). ## How much does continuous monitoring really cost over time? Continuous monitoring is the cost that never ends, and it is the one teams most consistently forget to multiply. Once you are authorized, FedRAMP requires an ongoing program of monthly and annual deliverables — not a one-time exercise. The official Rev 5 obligations that drive recurring labor include: - **Monthly vulnerability scanning** of operating systems, databases, web applications, and (where relevant) containers, with results reported on a defined cadence. - **A monthly continuous monitoring submission**, summarized for the authorizing official, that reports scan results and the current security posture. - **POA&M maintenance** — every open weakness from assessment or ConMon must be tracked, aged, and remediated against FedRAMP timelines. - **Vulnerability deviation requests** to document risk adjustments, false positives, and operational requirements. - **An annual assessment** in which a 3PAO independently tests a selected subset of controls every year. None of this is optional, and all of it is labor. In Boundera's analysis, ConMon and the annual reassessment are the largest *recurring* portion of the bill — a meaningful share of the $200K–$500K per year a Moderate system typically spends after authorization, and $500K–$1M per year at High. Over a three-year authorization horizon, recurring ConMon and reassessment costs frequently exceed the entire initial assessment. > Sources: FedRAMP [Continuous Monitoring Playbook](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/intro) and [Rev 5 documents & templates](https://www.fedramp.gov/rev5/documents-templates/) (POA&M, monthly executive summary, annual assessment, and deviation request templates). ## Why does internal staffing dominate the bill? Internal staffing dominates the bill because FedRAMP is a sustained operating program, not a project with an end date. The 3PAO invoice is a single moment; the people who keep your evidence current, write control narratives, run scans, and answer the assessor are on payroll for the life of the offering. Most authorized CSPs end up needing at least: - An **ISSO** or equivalent to own the security posture and the authorization package. - **Engineers** who can implement and maintain technical controls without derailing the product. - A **compliance or GRC lead** to manage documentation, POA&M, and the monthly ConMon submission. Fully loaded, each of these roles runs into six figures annually. That is why a program with a modest 3PAO fee can still cost $200K–$500K per year at Moderate — the vendor invoice is small next to the salaries keeping the authorization alive. GAO's finding that "lacking sufficient resources," including funding and staffing, was one of six top challenges providers reported is the same problem seen from the inside: FedRAMP is staff-heavy, and that staff cost is permanent. ## How does scope creep inflate FedRAMP cost? Scope creep inflates cost because every component inside your authorization boundary must be documented, hardened, scanned, and assessed — forever. The boundary is the single biggest lever on price, and it tends to expand quietly. Common ways the boundary grows beyond the original budget: - A new microservice, data store, or third-party integration is added "temporarily" and never removed from scope. - The team discovers that supporting services (logging, CI/CD, management tooling) belong inside the boundary after all. - A move from a single tenant to a more complex multi-tenant or hybrid architecture pulls in new components. - An impact-level change — for example realizing the workload needs High rather than Moderate — resets the baseline to a larger control set. Each addition multiplies downstream: more controls to implement, more evidence to collect, more assets to scan every month, and a larger annual assessment. This is also where **significant-change re-assessments** appear. When you make a major architectural change to an authorized system, FedRAMP can require additional 3PAO testing before that change is accepted — an event-driven fee that arrives outside any annual plan. A boundary defined loosely up front becomes a recurring tax on every release that follows. ## How does Boundera reduce the biggest hidden cost? The largest *recurring* hidden cost in FedRAMP is ongoing evidence collection and ConMon labor — the work of pulling configuration, scan, and identity data together every month, mapping it to controls, and keeping the POA&M and narratives in sync as the system changes. This is exactly the work automation is built to compress. In Boundera engagements, the recurring labor that automation reduces most is: - **Automated evidence collection** from cloud, identity, and monitoring systems, so engineers stop hand-gathering screenshots each cycle. - **Continuous control mapping**, keeping implementation narratives aligned with what the environment actually does. - **POA&M and ConMon upkeep tied to real tickets and infrastructure changes**, rather than spreadsheets maintained by hand. - **First-draft narratives and monthly summaries** that a compliance lead refines instead of writing from scratch every month. The point is not that FedRAMP becomes cheap — staffing, tooling, and the annual reassessment remain real. It is that the most repetitive, perpetual line item, ConMon evidence labor, is the one most responsive to automation, and shrinking it lowers the year-over-year cost that compounds across the life of an authorization. For the full picture, see our [full FedRAMP cost breakdown](/blog/20x/fedramp-cost-2026), the detailed [cost by impact level](/blog/rev5/fedramp-cost-by-impact-level), and how the newer path compares in our [FedRAMP 20x cost](/blog/20x/fedramp-20x-cost) guide. ## Frequently asked questions ### What is the most underestimated cost of FedRAMP? Internal labor — engineering, remediation, and dedicated compliance staff such as an ISSO. These costs rarely appear on a vendor quote, yet in Boundera's analysis they are usually the largest portion of both the initial spend and the annual run rate. ### Is the 3PAO fee the biggest FedRAMP cost? No. The 3PAO assessment runs $50K–$400K+ (with an optional Readiness Assessment Report adding $30K–$80K), but it is frequently the smaller half of the total. Internal staffing, tooling, and continuous monitoring usually cost more over a full authorization cycle. ### Does FedRAMP cost recur every year after authorization? Yes. Continuous monitoring (monthly scans, POA&M upkeep, monthly reporting) and the annual 3PAO reassessment are permanent obligations. A Moderate system typically spends $200K–$500K per year after authorization; a High system $500K–$1M per year. ### How much does continuous monitoring cost per year? ConMon and the annual reassessment make up the largest recurring share of FedRAMP spend — a meaningful slice of the $200K–$500K/year (Moderate) and $500K–$1M/year (High) ranges in Boundera's analysis. Over three years, recurring costs often exceed the initial assessment. ### Why do FedRAMP cost estimates vary so much? Because there is no single standard for measuring them. GAO found that estimates ranged from tens of thousands to millions of dollars, that actual cost data was limited, and that agencies and providers used inconsistent methods. Impact level, boundary size, and starting security maturity all move the number. ### What is a significant-change re-assessment and does it cost extra? When you make a major architectural change to an authorized system, FedRAMP can require additional 3PAO testing before the change is accepted. This is an event-driven fee that arrives outside your annual plan and is a common source of budget surprises. ### Can automation lower FedRAMP costs? It lowers the biggest *recurring* cost — ongoing evidence collection and ConMon labor — by automating data gathering, control mapping, and POA&M upkeep. It does not eliminate staffing, tooling, or the annual reassessment, but it shrinks the line item that compounds year over year. ## Sources - [FedRAMP Continuous Monitoring Playbook (Rev 5) — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/intro) - [FedRAMP Rev 5 Documents & Templates (POA&M, monthly executive summary, annual assessment, deviation request) — fedramp.gov](https://www.fedramp.gov/rev5/documents-templates/) - [GAO-24-106591, Cloud Security: Federal Authorization Program Usage Increasing, but Challenges Need to Be Fully Addressed — gao.gov](https://www.gao.gov/products/gao-24-106591) The cost figures in this guide reflect Boundera's own analysis of FedRAMP engagements, validated against the official program sources above. --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP Cost by Impact Level: Low vs Moderate vs High - URL: https://boundera.io/blog/rev5/fedramp-cost-by-impact-level - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:20Z - Reading time: 9 minutes - Main question: How much does FedRAMP cost by impact level? - TL;DR: FedRAMP cost scales with impact level: Low runs $250K-$500K initial plus $100K-$200K/yr ConMon; Moderate $500K-$1.5M initial plus $200K-$500K/yr (complex lifecycles can reach $2M-$5M); High $1M-$3M+ initial plus $500K-$1M/yr. Cost rises because each level adds controls, boundary scope, and assessment depth. - Excerpt: What FedRAMP costs by impact level: Low $250K-$500K, Moderate $500K-$1.5M, High $1M-$3M+ - plus ConMon, 3PAO fees, and why cost scales with controls. # FedRAMP Cost by Impact Level: Low vs Moderate vs High FedRAMP cost scales directly with impact level: **Low** runs roughly **$250K–$500K** to get authorized plus **$100K–$200K/year** to maintain, **Moderate** runs **$500K–$1.5M initial** plus **$200K–$500K/year**, and **High** runs **$1M–$3M+ initial** plus **$500K–$1M/year**. The reason is structural — each level up adds more controls to implement, a larger system boundary to assess, and a deeper, more expensive 3PAO engagement. **Key takeaways** - **Low** (≈156 controls): **$250K–$500K** initial, **$100K–$200K/yr** ConMon. The new **FedRAMP 20x Low** path can land lower, around **$100K–$300K** initial. - **Moderate** (≈323 controls): **$500K–$1.5M** initial, **$200K–$500K/yr** ConMon. A complex lifecycle with heavy remediation can reach **$2M–$5M**. This is the level most SaaS vendors actually need. - **High** (≈410 controls): **$1M–$3M+** initial, **$500K–$1M/yr** ConMon — reserved for the most sensitive unclassified, mission-critical systems. - The single largest cost driver is **control count**, which sets the scope of documentation, engineering, and the 3PAO assessment. - A **3PAO assessment** alone is **$50K–$400K+** (Moderate typically **$150K–$300K**); an optional **Readiness Assessment Report (RAR)** adds **$30K–$80K**. > Under the FedRAMP Consolidated Rules for 2026 (CR26), the "FedRAMP Authorized" designation becomes a single **FedRAMP Certified** label, and the impact tiers below are relabeled as **Certification Classes A–D**: Class B ≈ LI-SaaS/Low, Class C ≈ Moderate, Class D ≈ High (Class A is a new pilot baseline). The requirements behind each tier change only minimally. ## How much does FedRAMP cost by impact level? The short answer: pick your impact level and you have picked roughly 80% of your budget. Everything else — boundary size, cloud architecture, how mature your security program already is — moves you within the range, not across it. | Impact level | Approx. control count | Data it covers (FIPS 199) | Initial authorization cost | Annual ConMon | | --- | --- | --- | --- | --- | | **Low** | ~156 | Loss would cause **limited** adverse effect on operations, assets, or individuals | **$250K–$500K** | **$100K–$200K** | | **Moderate** | ~323 | Loss would cause **serious** adverse effect — most CUI and sensitive-but-unclassified data | **$500K–$1.5M** (complex: $2M–$5M) | **$200K–$500K** | | **High** | ~410 | Loss would cause **severe or catastrophic** effect — law enforcement, emergency services, financial, health, mission-critical | **$1M–$3M+** | **$500K–$1M** | > Sources: control counts derived from the NIST SP 800-53 Rev. 5 baselines as adopted by FedRAMP; cost figures are Boundera's own analysis (see Sources). The pattern is consistent across every engagement we see: each step up roughly **doubles** the control burden and the assessment depth, and cost follows. A Low authorization is a real project; a High authorization is a multi-year program. ## How much does FedRAMP Low cost? FedRAMP Low costs **$250K–$500K** to reach an initial authorization and **$100K–$200K per year** to maintain through continuous monitoring (ConMon). Low covers systems where a breach of confidentiality, integrity, or availability would cause only a **limited** adverse effect — public-facing or non-sensitive informational services, and many low-impact SaaS tools. Because the baseline is the smallest (around 156 controls), the documentation package, the engineering work, and the 3PAO assessment are all comparatively contained. The cheapest legitimate path to a Low authorization is now the **FedRAMP 20x Low** track, which we estimate at **$100K–$300K initial**. 20x leans on automated, machine-readable Key Security Indicators (KSIs) instead of a traditional narrative-heavy package, which cuts the manual assessment effort that drives a lot of legacy cost. If you genuinely only need Low and your agency accepts the 20x designation, this is the most efficient route available in 2026. ## Why is Moderate the most common level? Moderate is the default because it is the level the federal market actually buys. Most agency use cases involve **Controlled Unclassified Information (CUI)** or sensitive-but-unclassified data, and under FIPS 199 that data lands at the Moderate impact level — where a loss would cause a **serious** adverse effect on operations or individuals. That makes Moderate the practical floor for any SaaS vendor selling broadly into federal. It costs **$500K–$1.5M** to reach initial authorization and **$200K–$500K per year** in ConMon. Where it gets expensive is the lifecycle: a system with a sprawling boundary, lots of external integrations, or significant remediation findings can push the all-in initial spend into the **$2M–$5M** range once you account for repeated assessment cycles, engineering rework, and the labor to keep the package current. The jump from Low to Moderate is the steepest in the program. The control count roughly doubles (≈156 to ≈323), and the new families — deeper auditing, incident response, configuration management, and supply-chain controls — require real engineering, not just documentation. This is also where the 3PAO assessment fee climbs to **$150K–$300K** for a typical Moderate system. For help deciding whether you actually need Moderate or can defensibly stay at Low, see [how to choose your impact level](/blog/rev5/fedramp-low-moderate-high-impact-levels). ## When do you actually need FedRAMP High? You need FedRAMP High only when a compromise would cause a **severe or catastrophic** adverse effect — and in practice that means specific, high-stakes data: law enforcement, emergency services, financial systems, healthcare data, and other mission-critical unclassified workloads. If an agency hasn't explicitly required High, you almost certainly don't need it. High costs **$1M–$3M+** to reach initial authorization and **$500K–$1M per year** in ConMon. With around 410 controls — plus stricter parameter values, more frequent scanning, tighter incident-response timelines, and heavier physical and personnel-security requirements — High is less a compliance exercise and more a continuous security-operations commitment. In our experience, the most common mistake is targeting High prematurely. Many vendors achieve Moderate first, win business, and only pursue High when a specific buyer mandates it. Going straight to High without that demand signal often means paying for $1M+ of control scope you can't yet monetize. ## What makes higher levels cost more? Three structural drivers explain the entire curve, and all of them compound as impact level rises: 1. **Control count.** Low has ~156 controls, Moderate ~323, High ~410. Every additional control is documentation to write, a technical capability to implement, and evidence to maintain — month after month, not once. 2. **System boundary size.** Higher-impact systems tend to have larger, more tightly defined authorization boundaries. More in-scope components means more to inventory, scan, configure, monitor, and assess. A boundary that grows from a handful of services to dozens multiplies labor across the entire lifecycle. 3. **Assessment depth.** The 3PAO has to test every applicable control. More controls and a bigger boundary mean a longer, more expensive assessment. A Low assessment might run **$50K–$150K**; Moderate typically **$150K–$300K**; High can exceed **$400K**. An optional RAR adds **$30K–$80K** up front. There's a fourth, less visible driver: **ConMon scales too.** Annual monitoring isn't a flat fee — it tracks the size of your boundary and the strictness of your baseline. That's why High ConMon ($500K–$1M/yr) can cost more *every year* than an entire Low initial authorization. Many teams underestimate this; we break it down in [the hidden costs of FedRAMP](/blog/20x/fedramp-hidden-costs). ## How Boundera changes the cost math Most of the cost at every impact level isn't the 3PAO fee — it's the human labor to build and maintain the package: writing the System Security Plan, mapping controls to evidence, running scans, and keeping everything current through ConMon. That labor scales with control count, which is exactly why higher levels cost more. Boundera attacks that labor directly. We auto-inventory your cloud resources, map them to the applicable baseline (Low, Moderate, or High), and collect control evidence continuously rather than scrambling before each assessment. For the FedRAMP 20x Low path specifically, we generate machine-readable KSI evidence automatically — which is what makes the **$100K–$300K** 20x range achievable instead of theoretical. The result is fewer billable consulting hours, faster authorization, and ConMon that runs itself instead of consuming a full-time team. For the complete lifecycle breakdown including Rev 5 vs 20x and all fee categories, see our [full FedRAMP cost breakdown](/blog/20x/fedramp-cost-2026). ## Frequently asked questions ### How much does each FedRAMP impact level cost? FedRAMP Low costs **$250K–$500K** initial plus **$100K–$200K/yr** to maintain; Moderate costs **$500K–$1.5M** initial (up to $2M–$5M for complex systems) plus **$200K–$500K/yr**; High costs **$1M–$3M+** initial plus **$500K–$1M/yr**. Cost rises with control count, boundary size, and assessment depth. ### Why does FedRAMP Moderate cost so much more than Low? The control count roughly doubles from ~156 (Low) to ~323 (Moderate), and the added controls — deeper auditing, incident response, configuration management, supply-chain security — require real engineering work, not just documentation. The 3PAO assessment also climbs from roughly $50K–$150K to $150K–$300K. ### How much is a 3PAO assessment by itself? A 3PAO assessment runs **$50K–$400K+** depending on impact level and boundary size. A typical Moderate system runs **$150K–$300K**. An optional Readiness Assessment Report (RAR) adds **$30K–$80K** before the full assessment begins. ### Is FedRAMP 20x cheaper than the traditional path? Yes. For Low-impact systems, the **FedRAMP 20x Low** path is estimated at **$100K–$300K initial** — meaningfully below a traditional Rev 5 Low authorization — because automated, machine-readable KSI evidence replaces much of the manual documentation and assessment labor. ### Do I need FedRAMP High? Only if a compromise would cause severe or catastrophic harm — law enforcement, emergency services, financial, or healthcare data — or if an agency explicitly requires it. Most SaaS vendors should target Moderate first and pursue High only when a specific buyer mandates it. ### How much does ongoing FedRAMP continuous monitoring cost? ConMon costs **$100K–$200K/yr** at Low, **$200K–$500K/yr** at Moderate, and **$500K–$1M/yr** at High. It scales with boundary size and baseline strictness, and at High it can exceed the cost of an entire Low initial authorization every year. ### What's the cheapest way to get FedRAMP authorized? If you genuinely only need Low, the FedRAMP 20x Low path (~$100K–$300K) is the most cost-efficient route in 2026. Beyond that, the biggest lever at any level is reducing manual labor — automating evidence collection and ConMon — since labor, not 3PAO fees, is the largest cost component. ## Sources - [FedRAMP impact levels and baselines — fedramp.gov](https://www.fedramp.gov/rev5/baselines/) - [NIST SP 800-53 Rev. 5, Security and Privacy Controls — csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) - [NIST SP 800-53B, Control Baselines for Information Systems — csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/53/b/upd1/final) - [FIPS 199, Standards for Security Categorization — csrc.nist.gov](https://csrc.nist.gov/pubs/fips/199/final) - [GAO, federal cloud and FedRAMP cost oversight — gao.gov](https://www.gao.gov/) The cost figures in this guide reflect Boundera's own analysis of FedRAMP engagements, validated against the official program sources above. --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP Marketplace Explained: Listings & Statuses (2026) - URL: https://boundera.io/blog/rev5/fedramp-marketplace-explained - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:19Z - Reading time: 9 minutes - Main question: What is the FedRAMP Marketplace and what do its designations mean? - TL;DR: The FedRAMP Marketplace is the U.S. government's official public directory of cloud services assessed against FedRAMP requirements. As of June 2026 it uses three legacy designations - FedRAMP Ready, In Process, and Authorized - but those are being replaced under CR26 (the outcome of RFC-0020) by a single FedRAMP Certified designation with four Certification Classes (A-D) and redesigned lifecycle statuses. - Excerpt: What the FedRAMP Marketplace is, how listings work, and what each designation means in 2026 - including the shift to FedRAMP Certified and Validated. # FedRAMP Marketplace Explained: Listings, Statuses, and Designations (2026) The FedRAMP Marketplace is the U.S. government's official, public directory of cloud services that have been assessed against FedRAMP security requirements. As of June 2026 it lists offerings under three legacy designations — **FedRAMP Ready, In Process, and Authorized** — but those labels are being replaced under the FedRAMP Consolidated Rules for 2026 (CR26) with a single **FedRAMP Certified** designation, four assessment baselines named **Class A–D**, and a redesigned set of lifecycle statuses. If your cloud service wants federal agencies to find, trust, and reuse its security package, getting listed correctly on the Marketplace is the visible payoff of the entire authorization process. **Key takeaways** - The FedRAMP Marketplace ([marketplace.fedramp.gov](https://marketplace.fedramp.gov/)) is the single authoritative source agencies use to discover authorized cloud services, assessors (3PAOs/independent assessors), and agencies that have issued authorizations. - The legacy listing designations are **FedRAMP Ready**, **In Process**, and **Authorized**; only "Authorized" means the security package is complete and reusable by agencies. - Under CR26 — the outcome of RFC-0020, confirmed in notice **NTC-0004** — those labels become a single **FedRAMP Certified** designation covering both the Rev 5 and 20x paths, plus four **Certification Classes (A–D)** in place of the old Low/Moderate/High tiers. FedRAMP declined a separate "FedRAMP Validated" label; the two paths are shown via Marketplace filters. CR26 is due by the end of June 2026. - **FedRAMP Ready is being retired**, and a new **Preparation** listing state lets serious providers appear on the Marketplace much earlier (RFC-0021). - A Marketplace listing is **not** an agency Authorization to Operate (ATO). It signals that FedRAMP has packaged the security information; each agency still makes its own authorization decision. ## What is the FedRAMP Marketplace? The FedRAMP Marketplace is the official online directory, run by the FedRAMP Program Management Office (PMO) within GSA, that publishes the authorization status of cloud service offerings (CSOs) and the organizations supporting them. Federal agencies use it as the starting point when they need a cloud product that already meets a standardized federal security bar, because the program's core promise is "do once, use many times" — one rigorous assessment whose materials many agencies can reuse. The Marketplace catalogs three main types of entries: - **Cloud service offerings** — the SaaS, PaaS, and IaaS products themselves, each with a designation and status. - **Assessors** — the independent assessment organizations (historically called Third-Party Assessment Organizations, or 3PAOs) that validate a provider's security implementation. - **Agencies** — federal agencies that have sponsored or reused authorizations, which helps other agencies gauge real-world adoption. One important nuance: private cloud offerings built for a single customer are generally not listed, because their security packages are not reusable across the government and therefore do not serve the Marketplace's "do once, use many times" purpose. > Source: [FedRAMP Marketplace](https://marketplace.fedramp.gov/) and [help.fedramp.gov — How does a CSP get listed?](https://help.fedramp.gov/hc/en-us/articles/27703689134107-How-does-a-cloud-service-provider-CSP-get-listed-on-FedRAMP-s-Marketplace) ## What do the FedRAMP Marketplace designations mean? A **designation** tells an agency how far along a cloud service is in the FedRAMP process and whether its security materials are ready to be reused. As of mid-2026, the Marketplace is mid-transition: the three legacy designations remain widely referenced, while the new RFC-0020 designations are being rolled out. The table below lays out both, so you can read a listing regardless of which label it shows. | Designation | What it means | Status under 2026 changes | | --- | --- | --- | | **FedRAMP Ready** | A recognized assessor attested to the provider's readiness, and FedRAMP reviewed/approved a Readiness Assessment Report (RAR). Signals capability, not a completed authorization. | **Being retired** under RFC-0020 / RFC-0021; replaced by the new **Preparation** listing state. | | **In Process** | The provider is actively working toward authorization with a federal agency (historically also the Joint Authorization Board). Materials are not yet complete. | Replaced by lifecycle statuses such as **Agency Authorization In Process** and **Assessment by FedRAMP**. | | **Authorized** | The provider completed the FedRAMP process; the security package is available for agency review and reuse. The "finished" state agencies look for. | Relabeled simply **FedRAMP Certified** — the single new designation for both the Rev 5 and 20x paths. | | **FedRAMP Certified** *(new)* | The single official label for any completed FedRAMP authorization, on either the Rev 5 or 20x path. Every Certification carries a **Class (A–D)** that describes its assessment baseline. | New designation under CR26 (the outcome of RFC-0020). FedRAMP declined a separate "FedRAMP Validated" label and will use Marketplace filters to show the Rev 5 vs 20x path. | | **Certification Class A–D** *(new)* | The four assessment baselines that replace Low/Moderate/High: Class A (new pilot), Class B (LI-SaaS + Low), Class C (Moderate), Class D (High). | Replaces the FIPS 199 impact tiers. FedRAMP avoided numbered "levels" to prevent confusion with DoD Impact Levels. | A critical point FedRAMP states explicitly: a Certification **Class does not rank how secure a service is overall.** It describes the coverage and depth of the assessment materials available to agencies — how much information an agency has to work with when making its own risk decision. > Source: [RFC-0020 FedRAMP Authorization Designations](https://www.fedramp.gov/rfcs/0020/) ## How is a Marketplace listing different from an ATO? A Marketplace designation is **not** an Authority to Operate. This distinction sits at the heart of the 2026 relabeling. A FedRAMP designation means FedRAMP has packaged essential security information about a cloud service so that an agency *can* evaluate it; an **ATO** is a separate decision made by an individual agency's Authorizing Official to actually run that service for a specific use case. FedRAMP's own rationale for the rename is that "authorized" was being misread. Providers assumed it functioned as a government-wide ATO; agency staff sometimes adopted "authorized" services without their own review; and officials occasionally took on risk assuming FedRAMP or another agency was monitoring security on their behalf. Reserving the word "authorization" for the agency ATO step — consistent with OMB Circular A-130 and the NIST Risk Management Framework — is meant to remove that ambiguity. In practice: a Marketplace listing gets you in the door, but each agency still runs its own categorization and authorization before going live. If you're sizing up the broader process behind that listing, see our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025) and a breakdown of the [FedRAMP impact levels](/blog/rev5/fedramp-low-moderate-high-impact-levels) those designations historically map to. ## How do you get listed on the FedRAMP Marketplace? You get listed by entering one of FedRAMP's defined lifecycle stages and having FedRAMP confirm your status. Historically this meant earning a FedRAMP Ready designation (assessor attestation plus an approved RAR), then moving to In Process once an agency began sponsoring your authorization, and finally to Authorized once the package was complete. Under the 2026 changes, the on-ramp opens earlier and the stages are renamed. For the legacy Rev 5 agency authorization path, a cloud service offering moves through these Marketplace statuses (per RFC-0020): 1. **Preparation** — the provider is doing the foundational work to manage its security and privacy risks. This new state, defined in RFC-0021, lets companies appear on the Marketplace before they're near the finish line. 2. **Agency Authorization In Process** — an agency has told FedRAMP it has begun the authorization. 3. **Assessment by FedRAMP** — FedRAMP performs the final review that can result in Certification. The target is **under 30 days** when the package is genuinely complete. 4. **Continuous Monitoring** — the service is FedRAMP Certified and is maintaining its security posture under Rev 5 ConMon requirements. This is the intended end state. 5. **Remediation** — the provider is correcting a significant underlying issue. The 20x path follows a parallel set of statuses (Preparation → Prioritized → Assessment by FedRAMP → Persistent Validation → Remediation), reflecting its continuous, evidence-driven model rather than a point-in-time paperwork review. A few requirements worth flagging from RFC-0021's Marketplace Listings (MPL) process: - **Pick one path.** A provider must choose either Rev 5 Certification or 20x Validation for a given offering — not both. - **Statutory scope only.** The offering must be intended for direct agency use (integrated into a federal system getting an ATO) or indirect use (as a component inside another agency-used service). Products listed solely to support other frameworks like CMMC fall outside FedRAMP's scope. - **A Preparation listing has a clock.** Providers must meet Certified/Validated requirements within **12 months** of an initial Preparation listing or face removal from the Marketplace for at least six months. - **Pricing disclosure is coming.** RFC-0021 introduces a requirement to publish general pricing information, with an effective date of **August 26, 2026** — a notable reversal from the previous practice of not publishing pricing. > Source: [RFC-0021 Expanding the FedRAMP Marketplace](https://www.fedramp.gov/rfcs/0021/) ## What role does the FedRAMP PMO play in the Marketplace? The FedRAMP PMO — the program office inside GSA's Technology Transformation Services — owns and operates the Marketplace and is the gatekeeper for what appears on it. The PMO reviews readiness materials, confirms when a provider's status changes, performs the final assessment that results in Certification or Validation, and publishes the listing data agencies rely on. Under the 2026 rules, the PMO is also committing to transparency and speed targets it did not publish before. RFC-0021 sets a **14-day target** for FedRAMP to act on certain submissions (such as a Preparation listing or an Agency Authorization In Process notification) and a **30-day target** for the Certification or Validation assessment itself once a complete package is submitted. The PMO also commits to publishing de-identified activity data so the community can see how long Marketplace actions actually take. These targets are aspirational — FedRAMP notes they depend on demand and staffing — but they represent a meaningful shift toward measurable service levels. ## How is the Marketplace changing under 20x and CR26? The Marketplace is being restructured as part of the broader 2026 modernization, which the program is consolidating into the FedRAMP Consolidated Rules for 2026 (CR26) alongside the FedRAMP 20x initiative. The headline changes: - **New designations.** "FedRAMP Authorized" is being replaced by a single **FedRAMP Certified** label, and the Low/Moderate/High tiers become four **Certification Classes (A–D)** (RFC-0020 / NTC-0004). - **FedRAMP Ready is retiring.** The readiness designation goes away in favor of the new **Preparation** state, which lets serious providers list earlier and keep agencies updated on their progress. - **Number-based levels replace FIPS 199 tiers.** The old impact-level naming is being moved to a numbered system to reduce confusion between a FedRAMP designation and an agency's own system categorization. - **Broader listings.** Beyond cloud offerings and assessors, advisory/consulting firms can now be listed, and independent assessors face new attestation and pricing-transparency requirements (RFC-0021). - **Transparency and pricing.** FedRAMP will publish activity data on Marketplace actions, and providers will be required to disclose general pricing. If you're new to all of this, our overview of the 20x program and [how much FedRAMP costs](/blog/20x/fedramp-cost-2026) puts these Marketplace changes in the context of the path and budget you'll actually plan around. **A practical note for 2026:** because the relabeling is mid-rollout, you may see a listing described as "FedRAMP Authorized" in one place and "FedRAMP Certified, Class C" in another for the same service. Both can be correct during the transition — FedRAMP is auto-mapping existing authorizations to the new Certified label and Class. When in doubt, read the *status* (e.g., Continuous Monitoring vs. In Process/Assessment by FedRAMP) and confirm the exact entry on [marketplace.fedramp.gov](https://marketplace.fedramp.gov/) rather than relying on a third-party summary. ## Frequently asked questions ### What does "FedRAMP Authorized" mean on the Marketplace? It historically meant a cloud service completed the FedRAMP process and its security package is available for any agency to review and reuse. As of 2026 this label is being replaced by a single **FedRAMP Certified** designation (each carrying a Certification Class of A–D). Importantly, it still does not mean a government-wide green light to use the service — each agency must issue its own Authority to Operate. ### Is being on the FedRAMP Marketplace the same as having an ATO? No. A Marketplace listing means FedRAMP has assessed and packaged a service's security information. An **ATO** is a separate decision an individual agency's Authorizing Official makes to actually operate that service for a specific use. The 2026 designation rename (RFC-0020) exists specifically to make this separation clearer. ### What's the difference between "In Process" and "Authorized"? "In Process" means a provider is actively working toward authorization with a federal agency, but its package isn't finished — agencies cannot yet reuse it. "Authorized" (now Certified/Validated) means the assessment is complete and the package is available for agency review and reuse. Under the new lifecycle, "In Process" maps to statuses like *Agency Authorization In Process* and *Assessment by FedRAMP*. ### Is FedRAMP Ready going away? Yes. Under RFC-0020 and RFC-0021, the **FedRAMP Ready** designation is being retired and replaced by a new **Preparation** listing state. Preparation lets providers appear on the Marketplace earlier and keep agencies informed, but it carries a 12-month deadline to reach Certified/Validated status or risk removal. ### How long does it take to get listed? That depends on your stage. FedRAMP's 2026 targets (RFC-0021) call for acting on certain listing submissions within about **14 days** and completing the final Certification/Validation assessment within roughly **30 days** of a complete package. The full journey to a completed authorization, however, still typically spans many months of preparation, assessment, and remediation before that final review. ### Can a provider pursue both Rev 5 and 20x at the same time? No. Under the 2026 rules a provider picks one assessment path per offering — Rev 5 or 20x — to avoid duplicating government review, though both result in the same **FedRAMP Certified** designation. FedRAMP has indicated a path for Rev 5 services to transition to 20x will be offered in the future. ### Where can I verify a service's current Marketplace status? Go directly to [marketplace.fedramp.gov](https://marketplace.fedramp.gov/) and search for the offering. Because designations are mid-transition in 2026, the official Marketplace entry — not a press release or third-party blog — is the authoritative source for a service's current designation, level, and status. ## Sources - [FedRAMP Marketplace — marketplace.fedramp.gov](https://marketplace.fedramp.gov/) - [How does a CSP get listed on FedRAMP's Marketplace? — help.fedramp.gov](https://help.fedramp.gov/hc/en-us/articles/27703689134107-How-does-a-cloud-service-provider-CSP-get-listed-on-FedRAMP-s-Marketplace) - [RFC-0020 FedRAMP Authorization Designations — fedramp.gov](https://www.fedramp.gov/rfcs/0020/) - [RFC-0021 Expanding the FedRAMP Marketplace — fedramp.gov](https://www.fedramp.gov/rfcs/0021/) - [FedRAMP 20x Overview — fedramp.gov](https://www.fedramp.gov/20x/) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP 20x Cost: What to Expect in 2026 - URL: https://boundera.io/blog/20x/fedramp-20x-cost - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:18Z - Reading time: 9 minutes - Main question: How much does FedRAMP 20x cost in 2026? - TL;DR: FedRAMP 20x is expected to cost materially less than Rev 5, with attributed industry estimates putting initial 20x authorization around $100K-$300K versus $250K-$1.5M+ for Rev 5. Savings come from automation: KSIs and machine-readable evidence replace large written packages and long human-led 3PAO assessments. As of June 2026 these figures are still firming up as 20x enters wide-scale Phase 3 adoption. - Excerpt: FedRAMP 20x is expected to cost ~$100K-$300K initially versus $250K-$1.5M+ for Rev 5. Here's why automation lowers the bill and what still costs money. # FedRAMP 20x Cost: What to Expect in 2026 FedRAMP 20x is expected to cost materially less than traditional Rev 5 authorization, with attributed industry estimates putting initial 20x authorization in roughly the **$100K–$300K range** versus $250K–$1.5M+ for comparable Rev 5 paths. The savings come from automation: Key Security Indicators (KSIs) and machine-readable evidence replace the large written packages and long human-led assessments that drove most of the cost under Rev 5. As of June 2026 these figures are still firming up, because 20x is moving from closed pilots into wide-scale adoption under Phase 3. **Key takeaways** - Attributed published estimates place initial FedRAMP 20x authorization at roughly **$100K–$300K**, well below the $250K–$1.5M+ typical of Rev 5 Low and Moderate. - The cost mix flips: under 20x the **biggest spend moves to engineering and evidence automation**, not 3PAO labor and documentation. - Pilot participants reportedly reached authorization in **under two months**, versus the years of preparation typical for Rev 5. - 3PAO assessment shrinks because assessors **verify automated evidence** rather than reading static narratives line by line. - Continuous monitoring (ConMon) costs persist but should be lower per cycle because KSI validation runs continuously instead of in annual scrambles. - Numbers remain provisional: 20x entered Phase 3 (wide-scale adoption) in FY26 Q3, and pricing is still emerging. ## How much does FedRAMP 20x cost in 2026? The honest answer in June 2026 is that no official FedRAMP price list exists, but attributed market estimates have converged on a meaningfully lower number than Rev 5. Several published analyses place initial 20x authorization (Low and Moderate) in the **$100K–$300K** range, compared with widely-cited Rev 5 figures of $250K–$500K for Low and $500K–$1.5M for Moderate. These are ranges, not quotes. Your actual cost depends on how cloud-native your service already is, how much of your evidence you can automate, how mature your security engineering is, and which 3PAO you select. A SaaS provider already running infrastructure-as-code, centralized logging, and automated vulnerability management will sit at the low end. A team retrofitting an older architecture to produce machine-readable evidence will spend more on engineering before an assessment is even worthwhile. | Cost component | Traditional Rev 5 (Low–Moderate) | FedRAMP 20x (expected) | Direction | | --- | --- | --- | --- | | Documentation / SSP authoring | High (large written package) | Low (machine-readable package + KSIs) | Shrinks sharply | | 3PAO assessment | $30K–$45K (Low) up to $400K+ (higher tiers) | Smaller; assessor verifies automated evidence | Shrinks | | Internal labor / readiness prep | High, manual, recurring | Front-loaded into engineering automation | Shifts, often net lower | | Tooling / evidence automation | Optional add-on | Core requirement | Grows | | Continuous monitoring (annual) | $100K–$500K/yr | Lower per cycle via continuous KSI validation | Shrinks per cycle | | Initial total (attributed estimate) | $250K–$1.5M+ | ~$100K–$300K | Materially lower | > Sources: Rev 5 and 20x figures synthesized from published market estimates (Workstreet, Secureframe, A-LIGN, Paramify) and FedRAMP pilot outcomes at [fedramp.gov/20x](https://www.fedramp.gov/20x/). Treat all dollar figures as attributed ranges, not official pricing. ## Why is FedRAMP 20x cheaper than Rev 5? 20x is cheaper because it changes where the work happens, not just how fast it happens. Rev 5 cost is dominated by two things: producing a large written package (the System Security Plan, control narratives, policies, diagrams) and paying a 3PAO to manually review and test against hundreds of NIST SP 800-53 controls. Both are labor-intensive and recur every continuous-monitoring cycle. FedRAMP's own comparison frames 20x as "designed for automated demonstration of secure configurations and practices" rather than "extensive written narratives describing static security decisions." In practice that means: - **Documentation effort drops.** KSIs express security as a set of measurable, validated outcomes instead of long prose. The package becomes machine-readable rather than a 300-page document a human must author and another human must read. - **3PAO labor drops.** When evidence is automated and structured, the assessor's job shifts to confirming that the automated evidence is accurate and complete. That is faster than line-by-line narrative review, which compresses the assessment window and the bill. - **Time-to-authorization drops.** FedRAMP reports that 20x pilot participants reached authorization in under two months from start, versus years for traditional Rev 5. Less elapsed time means fewer consultant hours and less internal opportunity cost. - **No agency sponsor required.** Under 20x, FedRAMP reviews initial authorization requests directly rather than requiring an agency to invest resources to sponsor you in advance, removing a major early hurdle that often inflated Rev 5 timelines and cost. The mechanism, in one sentence: continuous, machine-readable evidence removes the manual labor that made Rev 5 expensive. ## What still costs money under FedRAMP 20x? 20x is cheaper, but it is not free, and the savings are not evenly distributed. Several costs persist or even grow: - **Security engineering.** This is the new center of gravity. To produce automated KSI evidence you need clean asset inventory, infrastructure-as-code, centralized logging, automated vulnerability management, and validation pipelines. For teams that already operate this way, it is cheap. For teams that do not, this is real engineering investment that must come before any assessment. - **Evidence automation tooling.** Under Rev 5, automation tooling was an optional accelerator. Under 20x it is a core requirement, because the model assumes continuous machine-readable validation. Phase 2 pilot participants were expected to automate a large majority of their evidence. - **3PAO assessment.** The fee shrinks but does not disappear. An independent assessor still confirms your automated evidence and produces the assessment that informs certification. - **Continuous monitoring.** ConMon obligations remain and are formalized under the 2026 rules. The good news is that continuous KSI validation replaces the annual documentation scramble, so the per-cycle cost should be lower and the work is spread out rather than spiking once a year. - **Specialized labor.** Whether in-house or consulting, you still need people who understand both FedRAMP requirements and the engineering needed to satisfy them automatically. The pattern is consistent: 20x trades manual compliance labor for up-front engineering. For a mature cloud-native SaaS team, that trade lowers total cost. For a team with weak inventory, inconsistent logging, and manual vulnerability response, the engineering bill can be significant — and 20x will expose those gaps quickly. ## How does automating KSI evidence lower the cost? The cost lever in 20x is automation of Key Security Indicators, and it is worth being concrete about how that translates to dollars. A KSI is a measurable security outcome that can be validated by machine — for example, "all production data is encrypted in transit" or "multi-factor authentication is enforced for all privileged access." Instead of writing a narrative claiming the control is in place and attaching a screenshot, you connect the system of record (your cloud provider, identity platform, vulnerability scanner) and produce continuous evidence that the outcome is true right now. This changes the economics in three places. First, it removes the authoring cost of long control narratives. Second, it removes the periodic re-collection cost — evidence refreshes automatically instead of being gathered by hand before each assessment and each ConMon cycle. Third, it shortens the assessment, because the 3PAO is checking that your automated pipeline reports the truth rather than re-deriving it from static artifacts. This is the mechanism Boundera is built around: connecting evidence sources, mapping them to KSIs, validating the outcomes continuously, and exporting a machine-readable package from current system data. The cost advantage of 20x is only real if the evidence pipeline is live; a stale pipeline produces a stale package, which is why "export a JSON file" is not a substitute for genuine evidence operations. If you want the detailed how-to, see our guide on how to [automate KSI evidence](/blog/20x/fedramp-20x-ksi-evidence-automation). ## How do 20x costs compare across FedRAMP Certification Classes? Under the FedRAMP Consolidated Rules for 2026 (CR26), all FedRAMP authorizations move to a single **FedRAMP Certified** label, and the legacy Low/Moderate/High impact categories are replaced by four **Certification Classes (A–D)**. The mapping matters for budgeting because the old language is being retired: | Certification Class | Maps to (legacy) | 20x cost expectation | | --- | --- | --- | | Class A | New pilot baseline | Lowest entry point | | Class B | LI-SaaS and Low | Low — covered by the Phase 1 / 2 pilots | | Class C | Moderate | Moderate — covered by the Phase 2 pilot | | Class D | High | Highest; a 20x High pilot is signaled for FY27 | For 20x specifically, Class B and Class C (the former Low and Moderate baselines) are where the program is live in 2026, and where the ~$100K–$300K attributed estimates apply. Class D (the former High baseline) is not yet available under 20x — FedRAMP has signaled a pilot in FY27 — so High-impact systems still run through Rev 5 today. For a complete picture across both programs, see our [full FedRAMP cost breakdown](/blog/20x/fedramp-cost-2026). ## Frequently asked questions ### How much does FedRAMP 20x cost? Attributed published estimates place initial FedRAMP 20x authorization (the former Low and Moderate baselines, now Certification Classes B and C) at roughly $100K–$300K, compared with $250K–$500K for Rev 5 Low and $500K–$1.5M for Rev 5 Moderate. These are market estimates, not official FedRAMP pricing, and they are still firming up as 20x moves into wide-scale adoption in 2026. ### Is FedRAMP 20x actually cheaper than Rev 5? For most cloud-native SaaS providers, yes. 20x replaces large written documentation packages and long manual 3PAO assessments with automated KSI evidence and machine-readable packages, which cuts both documentation effort and assessment labor. The savings are smaller for teams that must first build the engineering and automation needed to produce that evidence. ### What is the biggest cost in a FedRAMP 20x program? Security engineering and evidence automation. Under Rev 5 the biggest spend was assessors and documentation; under 20x it shifts to building the pipelines that produce continuous, machine-readable evidence of KSI outcomes. Teams already operating with infrastructure-as-code, centralized logging, and automated vulnerability management spend far less here. ### Does FedRAMP 20x still require a 3PAO assessment? Yes. An independent third-party assessment organization still validates your evidence, but its role changes. Instead of reading static narratives line by line, the 3PAO verifies that your automated evidence is accurate and complete, which shortens the assessment window and reduces the fee relative to Rev 5. ### How long does FedRAMP 20x take, and does speed reduce cost? FedRAMP reports that 20x pilot participants reached authorization in under two months from start, versus years for traditional Rev 5. Faster timelines reduce consultant hours and internal opportunity cost, which is a meaningful part of why 20x is cheaper overall — though the engineering to get assessment-ready can still take time. ### What does FedRAMP 20x continuous monitoring cost? ConMon obligations remain under 20x and are formalized in the 2026 rules, so it is not free. However, because KSI validation runs continuously instead of culminating in an annual documentation push, the per-cycle effort and cost should be lower and more evenly spread than the $100K–$500K/year typical of Rev 5 ConMon. ### Can High-impact systems use FedRAMP 20x yet? Not in 2026. 20x in 2026 covers the former Low and Moderate baselines (now Certification Classes B and C). High-impact systems (Class D, the former High baseline) are not yet available under 20x — FedRAMP has signaled a pilot in FY27 — so High-impact services still pursue Rev 5 today. Budget accordingly if you are High-impact. ## Sources - [FedRAMP 20x Overview — fedramp.gov](https://www.fedramp.gov/20x/) - [FedRAMP 20x Phased Implementation — fedramp.gov](https://www.fedramp.gov/20x/phases/) - [FedRAMP 20x Phase 2 Pilot Assessment — fedramp.gov](https://www.fedramp.gov/20x/phase-two/assessment/) - [Initial Outcome from RFC-0020: FedRAMP Authorization Designations — fedramp.gov](https://www.fedramp.gov/notices/0004/) The cost figures and ranges in this guide reflect Boundera's own analysis of FedRAMP and 20x engagements, validated against the official program sources above. --- _Last updated: June 2026. Written by the Boundera team._ ### How to Collect and Automate FedRAMP 20x KSI Evidence - URL: https://boundera.io/blog/20x/fedramp-20x-ksi-evidence-automation - Program: FedRAMP 20x - Category: Automation - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:17Z - Reading time: 15 minutes - Main question: How do you collect and automate FedRAMP 20x KSI evidence? - TL;DR: FedRAMP 20x KSI evidence is validated proof that each Key Security Indicator is met, and it must be both machine-readable and human-readable, regenerable on demand, and produced by persistent validation rather than screenshots. You automate it by connecting cloud config, vulnerability scanners, and your identity provider, mapping each signal to a KSI validation, and emitting a structured package on schedule. Machine-based resources must be validated at least every 7 days at Low and every 3 days at Moderate; non-machine validations at least every 3 months. - Excerpt: Collect and automate FedRAMP 20x KSI evidence: what counts, the 7-day/3-day validation cadence, why screenshots fail, and how to build the pipeline. # How to Collect and Automate FedRAMP 20x KSI Evidence FedRAMP 20x KSI evidence is the validated proof that each Key Security Indicator is being met inside your cloud service offering, and FedRAMP expects it to be both machine-readable and human-readable, regenerable on demand, and produced by persistent validation rather than one-time screenshots. You automate it by connecting authoritative data sources (cloud config APIs, vulnerability scanners, your identity provider, CI/CD), mapping each signal to a specific KSI validation, and emitting a structured package on a schedule. For machine-based resources, FedRAMP 20x requires validation at least every 7 days at Low and every 3 days at Moderate; non-machine-based validations must run at least once every 3 months. **Key takeaways** - KSI evidence must be **machine-readable and supported by automated technical validation whenever possible**, and the evidence file must be **regenerable on demand** with a data schema that maps it to KSI elements (FedRAMP 20x Phase One example, RFC-0006). - **Persistent machine validation cadence**: at least every **7 days at Low** and every **3 days at Moderate**; **High** is expected to be more frequent but is not yet finalized. **Non-machine validation**: at least once every **3 months** (PVA-CSX-PMV, PVA-CSX-NMV). - FedRAMP 20x organizes security outcomes into **11 KSI themes**, each containing multiple KSI validations with discrete IDs (for example, `KSI-IAM-MFA`). - Assessors **must not rely on screenshots or config dumps** as evidence except to test the process that generates them (PVA-TPX-STE). Static artifacts do not satisfy 20x. - A **failure of the validation process is treated as a vulnerability** and must be routed through Vulnerability Detection and Response (PVA-CSX-FAV). - The automatable share of KSI evidence is high but not total: machine-based checks (config, IAM, logging, encryption, exposure) automate cleanly; non-machine checks (training, incident exercises, policy approvals) still need a scheduled human process. ## What counts as KSI evidence in FedRAMP 20x? KSI evidence is the data a provider produces to demonstrate that a specific Key Security Indicator validation is true for the in-scope cloud service offering. In FedRAMP 20x, a KSI defines a security objective and lists multiple **KSI validations**; for each validation, the provider asserts true, false, or partial and supports that assertion with evidence ([FedRAMP 20x Phase One example](https://www.fedramp.gov/20x/phase-one/example/)). The defining shift from Rev 5 is the form the evidence takes. FedRAMP 20x does not want a control-by-control narrative backed by a folder of screenshots. It wants evidence that is: - **Machine-readable.** Authorization packages built on KSIs must be machine-readable, supported by evidence, and should include automated technical validation wherever possible. The provider produces a machine-readable file that addresses each KSI validation, assembled in a format of the provider's own design, with a data definition or schema explaining how the submission maps to KSI elements ([FedRAMP 20x Phase One example](https://www.fedramp.gov/20x/phase-one/example/)). - **Human-readable.** The same package must be reviewable by people. A 3PAO reviews the submission and adds signed attestations; FedRAMP makes the final decision from the assessor's findings. Evidence that only a parser can read does not pass independent review, and evidence that is only prose does not satisfy the machine-readable requirement. You need both. - **Regenerable on demand.** The Phase One example is explicit: the file can be regenerated on demand. That single requirement is why screenshots fail and why pipelines win. If you cannot re-run the collection and reproduce the current state, you do not have 20x evidence; you have a snapshot. - **Tied to a source and a timestamp.** For continuously reported validations, the machine-readable data should carry metadata of where and when the evidence was collected. A pass with no source and no time is not defensible. Put plainly: good KSI evidence states what was checked, which resource or process was checked, when, from which system, what the expected condition was, what the actual result was, whether it passed, and who owns remediation if it failed. Raw output without that context creates review work; context without raw output creates trust problems. For the full mapping model, see our [FedRAMP 20x KSI guide](/blog/20x/fedramp-20x-ksi-guide). ## What are the FedRAMP 20x KSI categories? FedRAMP 20x groups Key Security Indicators into **11 themes** for ease of review. Each theme is a cluster of related security outcomes, and each contains multiple individually identified KSI validations. The table below summarizes the current themes and how their evidence is typically collected. | KSI theme | Security outcome (paraphrased) | Dominant evidence type | | --- | --- | --- | | Authorization by FedRAMP | Meet 20x program requirements: scope, data sharing, crypto modules, VDR, change notifications, inbox, incident comms | Hybrid (process + machine) | | Change Management | All changes documented; configuration baselines kept current | Machine (CI/CD, IaC) + process | | Cloud Native Architecture | Use cloud-native design to enforce confidentiality, integrity, availability | Machine (cloud config) | | Cybersecurity Education | Educate and persistently test employees on security | Non-machine (training records) | | Identity and Access Management | Protect data, control access, apply zero trust | Machine (IdP / cloud IAM) | | Incident Response | Document, report, and analyze incidents | Hybrid (ticketing + process) | | Monitoring, Logging, and Auditing | Monitor, log, and audit important events and changes | Machine (SIEM / cloud logs) | | Policy and Inventory | Organized, universal guidance for how every resource is secured | Hybrid (inventory + policy) | | Recovery Planning | Define, maintain, and test recovery and continuity capabilities | Non-machine (test records) + machine (backups) | | Service Configuration | Encryption, integrity verification, restrict third-party resources | Machine (cloud config) | | Supply Chain Risk | Understand, monitor, and manage third-party resource risk | Hybrid (inventory + process) | > Source: [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) Each KSI carries a standardized ID. Inside Identity and Access Management, for example, the validations include `KSI-IAM-MFA` (enforce phishing-resistant MFA for all user authentication), `KSI-IAM-AAM` (manage account lifecycles using automation), `KSI-IAM-ELP` (persistently ensure least privilege), `KSI-IAM-JIT` (least-privileged, role/attribute-based, just-in-time authorization), and `KSI-IAM-SUS` (automatically disable privileged accounts on suspicious activity). Each KSI also lists its related NIST SP 800-53 controls, so a single IAM validation can map to dozens of Rev 5 controls at once ([FedRAMP 20x Identity and Access Management](https://www.fedramp.gov/docs/20x/key-security-indicators/identity-and-access-management/)). That control fan-out is exactly why automating a KSI is more efficient than evidencing each control by hand. Two program-level KSIs frame the rest. `KSI-CSX-SUM` requires providers to maintain a high-level implementation summary for each KSI, including pass/fail criteria, the consolidated information resources to be validated, the machine-based validation process and its persistent cycle, the non-machine-based process and its cycle, and current status. `KSI-CSX-MAS` says providers should apply all KSIs to everything within the FedRAMP Minimum Assessment Scope ([FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/)). ## How often must KSI evidence be validated? FedRAMP 20x sets different validation cadences for machine-based and non-machine-based information resources, and the machine-based cadence tightens with impact level. | Resource type | Low | Moderate | High | | --- | --- | --- | --- | | Machine-based | At least every **7 days** | At least every **3 days** | More frequent; requirement not yet established | | Non-machine-based | At least every **3 months** | At least every **3 months** | At least every **3 months** | > Source: [FedRAMP 20x Persistent Validation and Assessment — PVA-CSX-PMV, PVA-CSX-NMV](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) A **machine-based information resource** is one whose security state can be checked directly by automation: whether storage is encrypted, whether logging is enabled, whether a public endpoint is exposed, whether MFA is enforced in the identity provider. A **non-machine-based** resource is validated through a human process: a completed training cycle, a tabletop incident exercise, a signed policy approval, an executed recovery test. These numbers are floors, not targets. "At least every 3 days" at Moderate means the validation must run no less often than every 72 hours; nothing stops a provider from validating continuously, and many of the strongest pipelines do. The cadence requirement is what makes a once-a-quarter scanner run insufficient on its own and what makes persistent validation an operating model rather than an audit event. We cover the cadence and the assessor expectations behind it in our deep dive on [persistent validation](/blog/20x/fedramp-20x-persistent-validation), and how to wire the whole evidence pipeline into CI/CD in our walkthrough of [FedRAMP continuous monitoring automation](/blog/20x/fedramp-continuous-monitoring-automation). One subtlety changes how teams design pipelines: a **failure of the validation process is itself a vulnerability**. FedRAMP requires providers to treat issues detected during persistent validation, and failures of the validation process, as vulnerabilities to be handled under Vulnerability Detection and Response (PVA-CSX-FAV). A pipeline that silently stops collecting is not a passing pipeline; it is an open finding. ## Why don't screenshots count as KSI evidence? Screenshots and configuration dumps do not satisfy FedRAMP 20x because they are static. The assessor rules are direct: assessors **must not rely on screenshots, configuration dumps, or other static output as evidence, except when evaluating the accuracy and reliability of a process that generates such artifacts** (PVA-TPX-STE) ([Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/)). The reasoning follows from the rest of the model. Evidence must be regenerable on demand, carry collection metadata, and reflect current state across the whole boundary. A screenshot is none of those things: it cannot be diffed, queried, or re-verified, and it captures one resource at one moment. A screenshot can still help a human understand context, but it cannot be the system of record. This is also why assessors evaluate the **process**, not just the output. They must verify the effectiveness, completeness, and integrity of both the automated and the human validation processes, and confirm coverage across the offering, including whether every consolidated information resource listed is actually being validated (PVA-TPX-UNP). If you cannot explain how validation logic is defined, how missing resources are detected, and how stale evidence is caught, the output is hard to trust no matter how polished it looks. ## How do you automate KSI evidence collection? You automate KSI evidence by treating it as a data pipeline: pull current state from authoritative systems, normalize it into a common evidence model, evaluate it against each KSI validation's pass/fail criteria, and emit a structured, signed, regenerable package on the required cadence. The goal is not to remove human judgment; it is to make human judgment operate on current, structured evidence instead of manual exports. The automatable share is high. Machine-based KSI themes (Cloud Native Architecture, Identity and Access Management, Monitoring/Logging/Auditing, Service Configuration, much of Change Management) map cleanly to APIs and can be validated continuously. Non-machine themes (Cybersecurity Education, parts of Recovery Planning and Incident Response) still require a scheduled human process, but even those produce machine-readable result records: completion, recency, approval, and linkage to the KSI. Below is how the two approaches compare. | Dimension | Manual evidence collection | Automated KSI evidence pipeline | | --- | --- | --- | | Effort per cycle | High; re-gathered by hand each review | Low; runs on schedule with no re-gathering | | Cadence achievable | Quarterly or annual, realistically | Continuous; meets 3-day / 7-day floors | | Coverage | Sampled; gaps go unnoticed | Full boundary; missing resources detected | | Regenerable on demand | No | Yes (a 20x requirement) | | Source + timestamp metadata | Usually missing | Captured automatically | | Audit-readiness | Stale by review time | Current at the moment of review | | Drift detection | Manual and late | Immediate; failure raised as a vulnerability | The trade is clear. Manual collection cannot realistically hit a 72-hour Moderate cadence across an entire boundary, and it produces exactly the static artifacts assessors are told not to rely on. Automation is the only practical way to satisfy both the cadence floors and the regenerate-on-demand requirement at the same time. ## How do you build an automated KSI evidence pipeline? Here is a practical, step-by-step approach to building a KSI evidence pipeline that produces machine-readable and human-readable output on the FedRAMP 20x cadence. ### Step 1: Define the boundary and resource inventory Start with the FedRAMP Minimum Assessment Scope. List the consolidated information resources each KSI will validate, for example "all storage buckets in the production accounts" or "all employees in the Admin group." `KSI-CSX-SUM` requires this consolidated list, and assessors check whether every listed resource is actually being validated. If the boundary or inventory is wrong, coverage will be wrong no matter how good the automation is. ### Step 2: Connect authoritative data sources Pull from systems of record, not exports. Typical connections: - **Cloud configuration APIs** (AWS, Azure, GCP) for encryption, public exposure, logging enablement, and architecture checks. - **Identity provider and cloud IAM** (Okta, Entra ID, AWS IAM) for MFA enforcement, least privilege, privileged-group membership, and just-in-time access. - **Vulnerability scanners** such as Qualys or Tenable for detection coverage and remediation status. - **CI/CD and source control** (GitHub Actions, GitLab, pipelines) for change traceability and configuration baselines. - **SIEM and logging** for monitoring and audit coverage. - **Ticketing and policy repositories** for incident handling, approvals, and human-process evidence. Prefer APIs and structured logs over manual pulls so the collection itself can be re-run on demand. ### Step 3: Map every signal to a specific KSI validation This is the step most teams underinvest in. Each raw signal must point to a KSI ID with explicit pass/fail criteria. "MFA enforced for all user accounts in the IdP" maps to `KSI-IAM-MFA`; "all production storage encrypted at rest" maps to a Service Configuration validation. Record the expected condition, the resources in scope, the validation method (machine, non-machine, or hybrid), the cadence, and the owner. Because each KSI lists related SP 800-53 controls, one mapped validation often satisfies many Rev 5 controls at once. ### Step 4: Normalize into a common evidence model Convert every signal into one structured shape: KSI ID, resource, source system, expected state, observed state, result (pass/fail/partial/not-applicable), timestamp, and evidence reference. This common model is what makes the package both queryable by machines and summarizable for humans, and it is what lets you include the data schema FedRAMP asks for. ### Step 5: Evaluate against pass/fail criteria Run deterministic checks for machine-based resources. For non-machine resources, evaluate completion, recency, approval, and linkage to the KSI. Any failed validation, or any check that fails to run, becomes a vulnerability routed to an owner with the failed assertion and affected resource (PVA-CSX-FAV). ### Step 6: Generate human-readable and machine-readable output Emit the package in a machine-readable format with a data definition that maps records to KSI elements, plus a human-readable summary for each KSI. Carry source and timestamp metadata on every continuously reported validation, and make the whole file **regenerable on demand**, the explicit 20x requirement. ### Step 7: Schedule re-validation and route failures Run machine-based validations on a cadence that beats the floor (under 72 hours for Moderate, under 7 days for Low) and run non-machine validations at least quarterly. Failed checks should create durable work items, not Slack messages, with owners and expiration dates on any exceptions. ### Step 8: Prepare for independent assessment A FedRAMP-recognized assessor (or FedRAMP directly, for prioritized services) must assess your goals and validation processes, and their results go into your authorization data unmodified (PVA-CSX-IVV). Be ready to demonstrate how validation logic is defined, how coverage is proven, how evidence is protected from tampering, and how stale evidence is detected. ## How does Boundera automate KSI evidence? Boundera is an AI copilot built for exactly this pipeline. It connects to the same authoritative sources a 20x program depends on, including cloud configuration, identity providers, and vulnerability scanners such as Qualys and Tenable, then continuously collects current state rather than asking teams to re-gather it before each review. Where this becomes first-hand expertise rather than theory: in our own engagements, the work that consumes the most time is not running scanners, it is **mapping each signal to the right KSI validation with defensible pass/fail criteria and keeping that mapping current as the boundary changes**. Boundera uses AI control evaluation to propose those mappings, including the SP 800-53 controls each KSI rolls up, and flags resources that fall out of coverage so the consolidated information-resource list stays accurate. The output is a structured evidence package that is both machine-readable and human-readable, carries source and timestamp metadata, and regenerates on demand, the combination FedRAMP 20x requires. The honest framing is that automation does not erase the human process work. Cybersecurity education, recovery testing, and incident exercises still need a real cadence and real records. What automation does is collapse the machine-based majority of the KSI set into a continuous, low-effort flow, so the team's scarce time goes to the judgment-heavy non-machine validations and to fixing genuine findings. For how this affects total program economics, see our breakdown of [FedRAMP cost](/blog/20x/fedramp-cost-2026). ## What does a KSI evidence pipeline produce for assessors? It produces authorization data, not a written report. The strongest 20x submissions generate the assessor-facing package directly from current mappings and validation results: KSI assertions, evidence references, inventory, vulnerability response status, exceptions, and a per-KSI summary. The 3PAO then reviews that package and adds signed attestations for each KSI validation (Phase One example, Step Five). Assessors deliver a high-level summary of their findings for each KSI, and that summary becomes part of the cloud service offering's authorization data (PVA-TPX-SUM). Notably, assessors **do not** deliver an overall pass/fail recommendation; FedRAMP makes the final authorization decision from the assessor's findings and other information (PVA-TPX-NOR). That is one more reason the underlying evidence has to be defensible on its own: there is no single recommendation to hide behind. ## Frequently asked questions ### What is KSI evidence in FedRAMP 20x? KSI evidence is the validated data proving that a specific Key Security Indicator validation is true for the in-scope cloud service offering. Each KSI defines a security objective and lists multiple validations; the provider asserts true, false, or partial for each and supports it with evidence. In 20x that evidence must be machine-readable, supported by automated technical validation where possible, and regenerable on demand. ### Does KSI evidence have to be machine-readable? Yes. FedRAMP 20x authorization packages built on KSIs must be machine-readable and should include automated technical validation wherever possible. The provider produces a machine-readable file, in a format of their own design, that includes a data definition mapping the submission to KSI elements and that can be regenerated on demand. The same package also has to be human-readable so a 3PAO and FedRAMP can review it. ### How often does FedRAMP 20x require KSI validation? For machine-based information resources, validation must run at least every 7 days at Low and at least every 3 days at Moderate; the High cadence is expected to be more frequent but is not yet finalized. For non-machine-based resources, validation must be completed at least once every 3 months. These are minimum frequencies, and many providers validate machine-based resources continuously. ### Can I use screenshots as KSI evidence? No, not as your system of record. FedRAMP 20x assessors must not rely on screenshots, configuration dumps, or other static output as evidence, except when evaluating the reliability of the process that generates them. Screenshots cannot be regenerated on demand, diffed, or queried, so they fail the core requirements. Pull evidence from APIs, logs, and other authoritative systems instead. ### What happens if a KSI validation fails or the pipeline breaks? Both are treated as vulnerabilities. FedRAMP requires providers to handle issues found during persistent validation, and failures of the validation process itself, under the Vulnerability Detection and Response process. A pipeline that stops collecting is an open finding, so failures need an owner, a remediation path, and tracking, not a silent retry. ### How much of KSI evidence can be automated? Most of the machine-based themes (Cloud Native Architecture, Identity and Access Management, Monitoring/Logging/Auditing, Service Configuration, much of Change Management) can be validated continuously through APIs. Non-machine themes such as Cybersecurity Education and parts of Recovery Planning and Incident Response still require a scheduled human process, though their results can be captured as machine-readable records. FedRAMP does not publish a fixed automation percentage; it requires automated technical validation "whenever possible." ### How many KSI themes are there? FedRAMP 20x currently groups Key Security Indicators into 11 themes: Authorization by FedRAMP, Change Management, Cloud Native Architecture, Cybersecurity Education, Identity and Access Management, Incident Response, Monitoring/Logging/Auditing, Policy and Inventory, Recovery Planning, Service Configuration, and Supply Chain Risk. Each theme contains multiple individually identified KSI validations. ### Who reviews and attests to KSI evidence? A FedRAMP-recognized independent assessor (3PAO), or FedRAMP directly for certain prioritized services, reviews the package, validates the underlying processes, and adds signed attestations for each KSI validation. The assessor delivers a per-KSI summary that becomes part of the authorization data, but does not issue an overall recommendation; FedRAMP makes the final authorization decision. ## Sources - [FedRAMP 20x Key Security Indicators — fedramp.gov](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [FedRAMP 20x Identity and Access Management KSIs — fedramp.gov](https://www.fedramp.gov/docs/20x/key-security-indicators/identity-and-access-management/) - [FedRAMP 20x Persistent Validation and Assessment — fedramp.gov](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [FedRAMP 20x Phase One Pilot Participation Example — fedramp.gov](https://www.fedramp.gov/20x/phase-one/example/) - [FedRAMP RFC-0006: 20x Phase One Key Security Indicators — fedramp.gov](https://www.fedramp.gov/rfcs/0006/) - [NIST SP 800-53B (capabilities) — csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/53/b/upd1/final) --- _Last updated: June 2026. Written by the Boundera team._ ### How Much Does FedRAMP Cost in 2026? - URL: https://boundera.io/blog/20x/fedramp-cost-2026 - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP Guides - Published: 2026-06-04T12:00:00.000Z - Updated: 2026-06-17T20:43:16Z - Reading time: 13 minutes - Main question: How much does FedRAMP authorization cost in 2026? - TL;DR: Most CSPs should budget ~$250K-$2M+ for initial FedRAMP authorization plus $200K-$500K/year for continuous monitoring, depending on impact level and path. Rev 5 Moderate typically runs $500K-$1.5M to reach ATO; FedRAMP 20x is expected to land materially lower. - Excerpt: A 2026 breakdown of FedRAMP cost by impact level for Rev 5 and 20x, including 3PAO fees, ConMon, staffing, and the hidden costs CSPs miss. # How Much Does FedRAMP Cost in 2026? In 2026, most cloud service providers should budget roughly **$250K to $2M+ for initial FedRAMP authorization, plus $200K to $500K per year** for continuous monitoring — with the exact figure driven by impact level, system complexity, and whether you take the traditional Rev 5 path or the newer, automation-first FedRAMP 20x path. There is no single sticker price: the federal government itself does not set or publish authorization fees, and a 2024 GAO review found CSP and agency cost estimates ranging "from tens of thousands to millions of dollars." This guide breaks the number down by impact level and by component so you can build a defensible budget. **Key takeaways** - **FedRAMP has no official price.** Costs come from 3PAOs, consultants, tooling, and your own engineering time — not from FedRAMP itself. GAO has flagged the lack of standardized cost reporting as a known program gap. - **Rev 5 Moderate**, the most common path, typically runs **~$500K–$1.5M to reach authorization** and **~$200K–$500K/year** to maintain, based on published market ranges (figures vary widely by source and scope). - **3PAO assessment fees** alone commonly fall between **$50K and $400K+**, scaling with impact level and system complexity. - **Continuous monitoring (ConMon)** is the cost most teams underestimate — a recurring **$120K–$500K/year** in scans, annual assessment, tooling, and labor. - **FedRAMP 20x is expected to be materially cheaper.** Early pilot data and industry estimates point to **~$100K–$300K for 20x Low** and a meaningful drop for Moderate, primarily by replacing manual documentation and 3PAO labor hours with automated, machine-readable evidence. - **2026 is a transition year.** Under the FedRAMP Consolidated Rules for 2026 (CR26), every authorization moves to a single **FedRAMP Certified** label, and the Low/Moderate/High categories become four **Certification Classes (A–D)** (Class B ≈ LI-SaaS/Low, Class C ≈ Moderate, Class D ≈ High; Class A is a new pilot baseline). The underlying requirements — and therefore the cost drivers — change less than the labels do. ## Why doesn't FedRAMP publish an official cost? FedRAMP is a security assessment and authorization framework, not a paid certification scheme. The program (run by GSA) does not charge CSPs a fee, and it does not set or publish prices for the work required to get authorized. Your spend goes to private parties: a Third-Party Assessment Organization (3PAO), optional advisory or consulting firms, security and GRC tooling, and — usually the largest line item — your own staff's engineering and compliance time. That decentralization is exactly why cost estimates vary so wildly. In its 2024 report **GAO-24-106591**, the Government Accountability Office found that agencies and CSPs estimated FedRAMP authorization costs "anywhere from tens of thousands to millions of dollars," and noted the estimates were not comparable because there was no standardized method — or OMB guidance — for tracking and reporting authorization costs. In other words, when you see a precise dollar figure quoted as "the cost of FedRAMP," treat it with suspicion. The honest answer is a range, and the range depends on your starting maturity, your impact level, and how much of the work you automate versus pay people to do by hand. > Source: [GAO-24-106591, Cloud Security: Federal Authorization Program Usage Increasing, but Challenges Need to Be Fully Addressed](https://www.gao.gov/products/gao-24-106591) ## How much does FedRAMP cost by impact level? FedRAMP scopes the depth of assessment by impact level (FIPS 199: Low, Moderate, High; plus the simplified LI-SaaS path). More controls and stricter testing mean more 3PAO hours, more documentation, and more engineering work — so cost climbs roughly in step with the control count. Rev 5 control counts are approximately **156 (Low), 323 (Moderate), and 410 (High)**. The table below synthesizes commonly published 2026 market ranges. These are **estimated ranges, not quotes** — your real number depends on system complexity, existing security maturity, and how much you automate. | Impact level | Approx. controls | Initial authorization (est.) | Annual ConMon (est.) | | --- | --- | --- | --- | | **LI-SaaS / Low** | ~156 | $250K–$500K | $80K–$200K | | **Moderate** (most common) | 323 | $500K–$1.5M | $200K–$500K | | **High** | 410 | $2M–$3M+ | $500K–$1M | > Sources: Synthesized from published 2026 cost analyses by Secureframe, Vanta, Paramify, Knox Systems, and others (linked in Sources). Ranges differ by source; figures are directional, not guaranteed. A few honest caveats. The wide bands are real, not lazy. A security-mature SaaS already running centralized logging, MFA, FIPS-validated encryption, and clean documentation can land near the bottom of each range. A team treating FedRAMP as its first serious security program — building incident response, vulnerability management, and a full SSP from scratch — will feel every dollar at the top. For a sense of how that maps to calendar time, see [how long FedRAMP takes](/blog/rev5/how-long-does-fedramp-authorization-take). ## How much does FedRAMP Moderate cost? FedRAMP Moderate is the level most SaaS vendors selling to federal agencies need, because Moderate covers Controlled Unclassified Information (CUI). Published 2026 ranges for a Rev 5 Moderate authorization cluster around **$500K–$1.5M to reach an Authority to Operate (ATO)**, plus **~$200K–$500K per year** in continuous monitoring — though some analyses put the all-in lifecycle figure for a complex Moderate system as high as $2M–$5M when you count multiple years of ConMon, internal labor, and tooling. Why such a spread? Moderate's 323 controls require detailed, control-by-control narratives in the System Security Plan (SSP), broad vulnerability scanning, and a full 3PAO assessment. Most of the variance comes down to two things: how much remediation engineering you need before assessment, and whether you write hundreds of pages of documentation by hand or generate first drafts from your actual cloud configuration. The documentation and evidence work is where many Moderate budgets quietly balloon — and, as we'll cover below, it's also the part most amenable to automation. ## What does a FedRAMP budget actually break down into? It helps to stop thinking of FedRAMP as one bill and start thinking of it as four buckets. The table below shows the major cost components for a typical Rev 5 Moderate effort, with published 2026 ranges. Note that 3PAOs set their own prices, publish no rate cards, and scope engagements differently — so even within one bucket, two vendors can get very different quotes. | Cost component | What it covers | Typical range (est.) | One-time vs. recurring | | --- | --- | --- | --- | | **3PAO assessment** | Independent testing, SAP, SAR; annual reassessment | $50K–$400K+ initial | Both (annual reassessment) | | **Continuous monitoring** | Monthly scans, POA&M upkeep, annual assessment, ConMon reporting | $120K–$500K/year | Recurring | | **Internal staffing & engineering** | Remediation, SSP authoring, evidence collection, security leads | $200K–$350K+ | Mostly one-time, with recurring | | **Tooling & advisory** | GRC/SIEM/vuln-management tooling; optional consultants, RAR ($30K–$80K) | Tooling $75K–$250K/yr; advisory $100K–$500K+ | Both | > Sources: Synthesized from published 2026 breakdowns (Secureframe, Vanta, Paramify, Knox Systems, Workstreet, Elevate). 3PAO and ConMon figures align with the variability GAO documented in GAO-24-106591. The single most underestimated bucket is continuous monitoring, because it never ends. We'll come back to it — it's also where automation pays off most. ## How much does a 3PAO assessment cost? A 3PAO (Third-Party Assessment Organization) assessment commonly costs **between $50K and $400K+**, scaling with impact level and system complexity. Published 2026 ranges put Moderate 3PAO fees roughly in the **$200K–$650K** band for complex systems, and High assessments higher still, reflecting the larger control set and more intensive testing. There is an important honesty point here: **3PAOs do not publish rate cards.** They price each engagement based on the size of your authorization boundary, the number of components to test, the maturity of your evidence, and how much back-and-forth the assessment is likely to require. A clean, well-documented system with centralized evidence can be assessed in fewer hours than a sprawling boundary where the assessor has to chase artifacts. That's not a marketing claim — assessment is billed largely in labor, so anything that reduces assessor hours directly reduces the fee. Many CSPs also pay for a **Readiness Assessment Report (RAR)** first, typically **$30K–$80K**, to surface gaps before the formal assessment clock starts. (Note: under CR26, the standalone "Ready" designation is being retired in 2026, which may change how readiness engagements are packaged going forward.) ## What drives FedRAMP cost up or down? Two systems at the same impact level can differ by a million dollars. The drivers are predictable: - **Starting security maturity.** If MFA, FIPS-validated encryption, centralized logging, and tested incident-response and contingency plans already exist, you're closing gaps, not building from zero. Remediation engineering is often the biggest hidden cost. - **Authorization boundary size.** Every component inside the boundary must be documented, scanned, and assessed. A tight, well-defined boundary is cheaper than a sprawling one. Undocumented external connections are a classic source of findings — and rework. - **Documentation approach.** The SSP for a Moderate system runs hundreds of pages of control narratives. Writing them by hand, then keeping them in sync with reality, is slow and expensive. Generating first drafts from your live configuration is dramatically cheaper. - **Evidence discipline.** Scattered screenshots across tickets and wikis inflate both assessment hours and internal labor. A single system of record cuts both. - **Path: Rev 5 vs. 20x.** The traditional Rev 5 path front-loads documentation and 3PAO labor. FedRAMP 20x is built to shift spend toward engineering and automation, where it scales better. - **Use of consultants.** Advisory firms add real value on strategy and review, but consulting is among the most expensive line items ($100K–$500K+). It's a lever you can pull harder or softer. ## How much does FedRAMP continuous monitoring cost per year? Continuous monitoring (ConMon) typically costs **$120K–$500K per year** for a Moderate system, and more for High — and it is the recurring cost that catches teams off guard. FedRAMP authorization is not "set it and forget it." Once you have an ATO, you must run monthly vulnerability scans, keep your Plan of Action & Milestones (POA&M) current, update inventory, submit monthly ConMon executive summaries, and undergo a **full annual assessment** by a 3PAO. Each of those activities consumes tooling spend and labor month after month. The annual reassessment alone is a meaningful repeat 3PAO fee. Remediation SLAs add pressure: under FedRAMP standards, Critical findings must be fixed in 30 days, High in 90, Moderate in 180, and Low in 365 — so a backlog of open POA&M items isn't just a paperwork problem, it's a staffing commitment. Over a typical multi-year ATO, cumulative ConMon spend frequently exceeds the initial authorization cost. Budgeting only for "getting to ATO" and not for the years after is one of the most common — and most expensive — planning mistakes CSPs make. ## How does automation reduce FedRAMP cost? The expensive parts of FedRAMP are not the deeply technical security controls — they're the **documentation and evidence work that repeats forever**. This is the specific problem automation attacks, and it's where a platform like Boundera focuses. Three areas see the biggest cost reduction: - **Documentation (SSP generation).** Instead of authoring hundreds of pages of Appendix A control narratives by hand, AI-driven tooling can map your actual cloud, identity, and CI/CD configuration to NIST 800-53 controls and generate first-draft narratives that compliance leads refine — collapsing a six-month manual phase into something far shorter. Because assessment is billed in labor, cleaner, consistent documentation also means fewer assessor hours. - **Continuous evidence collection.** Pulling configuration and logging evidence from AWS, Azure, GCP, Okta, and GitHub automatically — rather than collecting screenshots by hand each month — is what makes ConMon sustainable rather than a recurring fire drill. Since ConMon is the cost that never stops, automating it compounds in your favor every year after the first. - **Control evaluation kept in sync.** When control mappings, POA&M items, and SSP language stay automatically tied to real infrastructure changes, you avoid the drift that turns the annual assessment into an expensive scramble. The exact savings vary by team, but the mechanism is consistent: automation reduces the **labor hours** that make up most of a FedRAMP bill, in both the initial push and — crucially — every year of continuous monitoring after it. That's also the design philosophy behind FedRAMP 20x. ## Will FedRAMP 20x make it cheaper? Yes — FedRAMP 20x is explicitly designed to be **faster and cheaper** than the traditional Rev 5 path, and early data backs that up. 20x replaces lengthy written narratives with **Key Security Indicators (KSIs)** and machine-readable, automation-validated evidence, with the goal of cutting the manual documentation and 3PAO labor that dominate traditional costs. Early industry estimates put **20x Low initial authorization around $100K–$300K**, and some Phase Two pilot analyses suggest 20x Moderate could land materially below legacy Moderate's $2M–$5M lifecycle range — primarily because automation reduces assessor hours. A few important 2026 caveats. The 20x Phase 1 Low pilot ran in 2025 (12 of 26 submissions received authorizations), and the Phase 2 Moderate pilot ran into 2026; broad public availability of formal 20x paths is widely expected in **late 2026**, so firm pricing is still settling. The two paths are also **not interchangeable** under the forthcoming rules — work toward a Rev 5 certification does not transfer to 20x, and vice versa. Under 20x, the biggest spend shifts to **engineering and automation tooling** rather than documentation and assessors, which is good news for technically strong teams and a different planning challenge for teams that were relying on consultants to write their way through. For a deeper dive on the numbers, see our [FedRAMP 20x cost](/blog/20x/fedramp-20x-cost) breakdown. ## What's changing about FedRAMP cost labels in 2026 (CR26)? If you're budgeting in 2026, know that the **vocabulary is changing even where the costs aren't**. Under the FedRAMP Consolidated Rules for 2026 (CR26), expected to publish by the end of June 2026 and valid through 2028: - "FedRAMP Authorized" is being replaced by a single official label, **FedRAMP Certification** / **FedRAMP Certified**, that applies to both the Rev 5 and 20x paths. FedRAMP declined a separate "FedRAMP Validated" label for 20x; the two paths are distinguished by filters in the Marketplace instead. The new name exists to reduce confusion with an agency's own Authority to Operate (ATO). - The FIPS 199 impact labels (Low/Moderate/High) are being replaced by four **FedRAMP Certification Classes (A–D)** — Class A is a new pilot baseline, Class B covers LI-SaaS and Low, Class C covers Moderate, and Class D covers High. FedRAMP deliberately avoided numbered "levels" to prevent confusion with DoD Impact Levels, and has stated the underlying baseline **requirements change only minimally** — the relabeling is about clarity, not new work. - FedRAMP will publish CR26 by the end of June 2026, and the rules will be valid through December 31, 2028. Expect a transition period during which the old and new labels are linked. The practical budgeting takeaway: the cost drivers in this guide — 3PAO labor, documentation, ConMon, tooling, staffing — carry over largely intact under CR26. The labels on your invoice and marketplace listing will change more than the dollar amounts. To understand how authorized offerings are listed and reused across agencies, see the [FedRAMP Marketplace](/blog/rev5/fedramp-marketplace-explained) explainer. > Source: [NTC-0004, Initial Outcome from RFC-0020 FedRAMP Authorization Designations (fedramp.gov)](https://www.fedramp.gov/notices/0004/) ## Frequently asked questions ### How much does FedRAMP cost in 2026? There is no fixed price. Most CSPs should budget roughly **$250K–$2M+ for initial authorization** and **$200K–$500K/year** for continuous monitoring, depending on impact level and path. GAO has documented estimates ranging "from tens of thousands to millions of dollars," so any single precise figure should be treated as one scenario, not the rule. ### How much does FedRAMP Moderate cost? Published 2026 ranges put Rev 5 Moderate at roughly **$500K–$1.5M to reach an ATO**, plus **$200K–$500K/year** in continuous monitoring. Some all-in lifecycle estimates for complex Moderate systems reach $2M–$5M once multiple years of ConMon, internal labor, and tooling are counted. Moderate is the most common level because it covers Controlled Unclassified Information (CUI). ### How much does a 3PAO assessment cost? 3PAO assessment fees commonly fall between **$50K and $400K+**, scaling with impact level and system complexity. 3PAOs don't publish rate cards; they price by boundary size, component count, and evidence readiness. A Readiness Assessment Report (RAR) beforehand typically costs $30K–$80K. ### What does FedRAMP continuous monitoring cost per year? Continuous monitoring typically runs **$120K–$500K per year** for a Moderate system, covering monthly vulnerability scans, POA&M upkeep, inventory updates, ConMon reporting, and a full annual 3PAO reassessment. Over a multi-year ATO, cumulative ConMon spend often exceeds the initial authorization cost. ### Is FedRAMP 20x cheaper than the traditional path? Yes, that's the explicit goal. Early estimates put **20x Low around $100K–$300K**, and pilot analyses suggest 20x Moderate could land materially below legacy Moderate. 20x cuts cost by replacing written narratives with Key Security Indicators and automated, machine-readable evidence, reducing 3PAO labor hours. Firm public pricing is still settling as formal 20x paths open, expected in late 2026. ### Does FedRAMP charge a fee to get authorized? No. FedRAMP (run by GSA) does not charge CSPs a fee or set prices. All FedRAMP costs are paid to private parties — 3PAOs, consultants, tooling vendors — plus your own internal engineering and compliance labor. This is a major reason cost estimates vary so widely. ### What's the difference between "FedRAMP Authorized" and "FedRAMP Certified" in 2026? Under the FedRAMP Consolidated Rules for 2026 (CR26), "FedRAMP Authorized" is being replaced by a single label — **FedRAMP Certified** — that covers both the Rev 5 and 20x paths (FedRAMP declined a separate "FedRAMP Validated" label). The Low/Moderate/High impact tiers become four **Certification Classes (A–D)**, where Class B ≈ Low, Class C ≈ Moderate, and Class D ≈ High. FedRAMP has said the underlying baseline requirements change only minimally, so the relabeling affects vocabulary more than cost. ### Can automation actually lower my FedRAMP bill? Yes, because most of a FedRAMP bill is labor — documentation, evidence collection, and assessment hours — not the controls themselves. Automating SSP generation, continuous evidence collection from your cloud and identity systems, and control mapping reduces those hours in both the initial authorization and, more importantly, every year of continuous monitoring that follows. ## Sources - [GAO-24-106591 — Cloud Security: Federal Authorization Program Usage Increasing, but Challenges Need to Be Fully Addressed (U.S. GAO)](https://www.gao.gov/products/gao-24-106591) - [NTC-0004 — Initial Outcome from RFC-0020 FedRAMP Authorization Designations (fedramp.gov)](https://www.fedramp.gov/notices/0004/) - [FedRAMP 20x Overview (fedramp.gov)](https://www.fedramp.gov/20x/) - [RFC-0020 — FedRAMP Authorization Designations (fedramp.gov)](https://www.fedramp.gov/rfcs/0020/) The cost figures and ranges in this guide reflect Boundera's own analysis of FedRAMP engagements, validated against the official program sources above. For the full process end-to-end, see our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025). --- _Last updated: June 2026. Written by the Boundera team._ ### Why OSCAL Alone Is Not FedRAMP 20x Readiness - URL: https://boundera.io/blog/20x/oscal-alone-is-not-fedramp-20x-readiness - Program: FedRAMP 20x - Category: Automation - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:15Z - Reading time: 6 minutes - Main question: Is OSCAL enough for FedRAMP 20x readiness? - TL;DR: No. OSCAL is useful for structured package data, but 20x readiness depends on current evidence, persistent validation, VDR, and authorization data sharing. - Excerpt: Structured files help, but FedRAMP 20x requires live evidence, KSI validation, VDR, and authorization data sharing. ## OSCAL is useful, but it is not the whole system [OSCAL](/blog/20x/oscal-for-fedramp-guide) is a valuable standard for representing security information in structured formats. It can make packages easier to validate, generate, diff, and exchange. But OSCAL alone does not make a provider FedRAMP 20x-ready. FedRAMP 20x depends on current authorization data, Key Security Indicators, persistent validation, vulnerability detection and response, and evidence that reflects the real operating state of the cloud service offering. A schema can carry that information. It cannot create the truth by itself. ## The common misconception The misconception sounds like this: "If we can export JSON or OSCAL, we are ready for 20x." That is too shallow. A machine-readable export is only as good as the system that produced it. If the inventory is stale, the evidence is manual, the KSI map is incomplete, and vulnerability status lives in a disconnected tracker, the export is just stale compliance data in a modern format. ## What OSCAL can help with OSCAL and structured package data are genuinely useful. They can help teams: - Represent control and system information consistently - Generate human-readable package artifacts - Validate required fields - Compare package versions - Reduce copy/paste errors - Exchange package data across tools - Create a source of truth for security documentation If your starting point is an existing Rev5 package, the mechanics of [converting that SSP into OSCAL](/blog/20x/ssp-to-oscal-guide) are a separate exercise from 20x readiness. Those are real wins, especially for teams moving away from Word documents and spreadsheets. ## What OSCAL cannot do by itself OSCAL does not automatically: - Define the authorization boundary - Discover in-scope resources - Validate cloud configurations - Prove MFA is enforced - Confirm logging coverage - Triage vulnerabilities - Route remediation work - Approve exceptions - Keep authorization data current - Show that validation processes are complete and reliable Those require evidence sources, validation logic, workflows, ownership, and review. ## FedRAMP 20x needs live evidence The core 20x question is not "Can you export a file?" It is: - Can you show what is in scope? - Can you show which KSIs apply? - Can you show current validation results? - Can you show where the evidence came from? - Can you show what happens when validation fails? - Can you show current vulnerability response status? - Can you share authorization data with the right parties? Structured formats help answer those questions, but only if they are backed by current operational data. ## A better architecture Think of OSCAL or machine-readable package output as the final mile, not the foundation. The foundation should be: 1. Boundary and inventory 2. KSI mapping 3. [Evidence source connections](/blog/20x/fedramp-20x-ksi-evidence-automation) 4. Persistent validation 5. Vulnerability detection and response 6. Exception and remediation workflows 7. Authorization data sharing 8. Human-readable and machine-readable package exports If you start at step 8, the package will look modern but behave like old compliance. ## How to evaluate a vendor claim If a vendor says they support 20x because they export structured files, ask: - Where does the evidence come from? - How often does it refresh? - Which KSIs are validated automatically? - How are non-machine KSIs tracked? - How are failed validations routed? - How are exceptions approved and expired? - How does VDR data flow into the package? - Can agencies access current authorization data? - Can an assessor review the validation process? The answers matter more than the file extension. ## Key takeaways - OSCAL and structured exports are useful, but they are not FedRAMP 20x readiness by themselves. - 20x requires current evidence, KSI validation, VDR, and authorization data sharing. - A machine-readable package should be generated from live evidence operations. - The strongest 20x program starts with the operating model, then exports the package. ## References - [FedRAMP 20x Overview](https://www.fedramp.gov/20x/) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [Authorization Data Sharing](https://www.fedramp.gov/docs/20x/authorization-data-sharing/) - [FedRAMP Automation](https://github.com/GSA/fedramp-automation) ### How to Prepare Your Engineering Team for FedRAMP 20x - URL: https://boundera.io/blog/20x/engineering-readiness-fedramp-20x - Program: FedRAMP 20x - Category: Automation - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:14Z - Reading time: 7 minutes - Main question: What does engineering need to do for FedRAMP 20x readiness? - TL;DR: Engineering should own boundary clarity, automatic inventory, evidence sources, validation workflows, exceptions, and remediation routing. - Excerpt: A practical engineering readiness checklist for boundary, inventory, evidence, validation, VDR, and assessor review. ## FedRAMP 20x is an engineering program FedRAMP 20x cannot be handled by compliance alone. The model depends on current inventory, source-linked evidence, persistent validation, vulnerability response, authorization data sharing, and repeatable security outcomes. Most of that data lives in engineering systems. If engineering is not involved early, 20x becomes a documentation project pretending to be an automation project. ## Start with boundary ownership The first engineering task is boundary clarity. Engineering should help define: - Which cloud accounts, projects, subscriptions, and clusters are in scope - Which environments are in scope - Which services and APIs are in scope - Which data stores and queues are in scope - Which CI/CD systems can affect production - Which identity paths administer the system - Which third-party services are part of the offering Compliance can document the boundary, but engineering needs to validate that it reflects reality. ## Make inventory automatic A 20x-ready inventory should not be manually maintained in a spreadsheet. Pull inventory from: - Cloud resource APIs - Kubernetes or container platforms - Identity providers - Source control - CI/CD systems - Vulnerability scanners - Logging systems - Asset management tools Every in-scope resource should have an owner, environment, source system, scope status, and last-seen timestamp. Inventory is the foundation for KSI validation. If inventory is wrong, validation coverage is wrong. ## Identify authoritative evidence sources For each major KSI area, decide where the evidence should come from. Examples: - MFA and privileged access: identity provider - Encryption: cloud configuration APIs - Logging: cloud logging and SIEM systems - Change control: CI/CD and source control - Vulnerabilities: scanners and dependency tools - Incident response: ticketing and incident systems - Training: HR or training platform - Recovery: backup and restore systems The goal is to [reduce manual evidence collection and make evidence refreshable](/blog/20x/fedramp-20x-ksi-evidence-automation). ## Build validation into normal workflows Persistent validation should not feel like a separate compliance ceremony. It should connect to normal engineering loops: - Pull request checks - Infrastructure-as-code validation - CI/CD gates - Cloud configuration checks - Runtime monitoring - Vulnerability intake - Ticket routing - Exception workflows When a validation fails, the system should tell the right owner what failed, where it failed, and how to fix it. ## Treat exceptions like production risk Exceptions are normal. Unowned exceptions are dangerous. Every exception should include: - Affected KSI or validation - Affected resource - Business reason - Compensating control - Owner - Approver - Expiration date - Review cadence This is an engineering hygiene issue, not just a compliance note. ## Prepare for assessor questions Assessors will care about the integrity of the validation process. Engineering should be ready to explain: - How validation logic works - How source systems are authenticated - How evidence is protected - How coverage is calculated - How failed checks are routed - How stale evidence is detected, given [how often each validation must run](/blog/20x/fedramp-20x-ksi-validation) - How changes affect validation results The strongest answer is a working system, not a slide deck. ## 30-day engineering readiness checklist Use this as a starting sprint: - Confirm the target class and expected boundary - Produce a current in-scope resource inventory - Identify evidence sources by KSI theme - Connect cloud, identity, CI/CD, scanner, and source control data - Run initial validation checks for IAM, logging, encryption, exposure, and vulnerability posture - Route failures to technical owners - Define exception rules - Generate a draft KSI evidence view from current data This will expose gaps quickly. That is the point. ## Key takeaways - FedRAMP 20x readiness depends on engineering systems and [tooling](/blog/20x/best-fedramp-compliance-tools-2026), not just compliance documents. - Boundary, inventory, evidence sources, validation, and remediation should be owned jointly. - Validation failures should create engineering work with clear ownership. - Assessor readiness depends on explaining how the validation machinery works. ## References - [FedRAMP 20x Overview](https://www.fedramp.gov/20x/) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [Vulnerability Detection and Response](https://www.fedramp.gov/docs/20x/vulnerability-detection-and-response/) ### Should You Start with Rev5 or FedRAMP 20x? - URL: https://boundera.io/blog/20x/rev5-or-20x-which-path - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP Guides - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:13Z - Reading time: 6 minutes - Main question: Should a CSP pursue Rev5 or FedRAMP 20x first? - TL;DR: Evaluate 20x first for new cloud-native SaaS targeting Class A, B, or C. Use Rev5 for Class D, non-cloud-native systems, and many existing authorization paths. - Excerpt: A decision guide for choosing between the traditional Rev5 path and the cloud-native FedRAMP 20x path. ## The decision matters early Choosing between FedRAMP Rev5 and FedRAMP 20x is not just a branding choice. It affects your authorization path, evidence model, engineering work, assessor expectations, and sales timeline. Some providers should pursue 20x. Some should stay with Rev5. Some should finish the Rev5 path they already started while building 20x-friendly evidence practices for the future. The right answer depends on your architecture, target class, agency needs, and current stage. ## Choose 20x when the system is cloud-native [FedRAMP 20x](/blog/20x/fedramp-20x-roadmap-2026) is designed for cloud-native commercial services built on FedRAMP Certified infrastructure and platforms. It is usually worth evaluating first when: - You are a new SaaS provider entering federal markets. - Your service runs on major cloud infrastructure or managed platforms. - You do not operate your own physical datacenter boundary. - You can collect evidence from APIs, logs, identity systems, CI/CD, and scanners. - You are targeting Class A, B, or C. - You want a program certification path that does not begin with a traditional agency sponsor. 20x favors teams that can keep evidence current and demonstrate security outcomes repeatedly. ## Choose Rev5 when the system needs the traditional path Rev5 remains important. It is usually the better path when: - You need Class D. - You operate non-cloud-native infrastructure. - You manage physical infrastructure or datacenter controls directly. - You already have a Rev5 authorization to maintain. - You are deep into an active Rev5 assessment and switching would create delay. - Your agency customer specifically requires the agency certification path. Rev5 is not "wrong." It is just a different operating model. For many high-impact, legacy, or infrastructure-heavy services, it remains the practical path. ## Do not switch lanes casually One of the biggest mistakes is trying to pivot midstream because 20x sounds faster. If you already have: - A defined Rev5 boundary - A [3PAO](/blog/rev5/fedramp-3pao-assessors) engaged - SSP work underway - Agency sponsor commitments - Assessment planning in motion then switching paths may create more confusion than progress. Instead, finish the current path and improve the underlying evidence system so future transition work is easier. ## Build evidence practices that help both paths Even if you choose Rev5, you can build in a 20x-friendly way. Invest in: - Structured inventory - Evidence source mapping - Cloud and identity API collection - Vulnerability workflow integration - Machine-readable package data - Control and [KSI crosswalks](/blog/20x/fedramp-20x-ksi-evidence-automation) - Change traceability - Current authorization data discipline These practices reduce Rev5 pain and prepare the organization for a more automated FedRAMP future. ## Decision table | Situation | Better default | | --- | --- | | New cloud-native SaaS targeting federal buyers | Evaluate 20x first | | Existing Rev5 authorized provider | Maintain Rev5, modernize evidence | | Class D or mission-critical service | Rev5 | | Non-cloud-native or physical infrastructure-heavy service | Rev5 | | Already deep into Rev5 assessment | Usually finish Rev5 | | Class B or C SaaS with strong engineering telemetry | 20x | This table is a starting point, not legal advice. Validate against current FedRAMP rules and agency expectations before committing. ## What to ask internally Before choosing a path, ask: 1. What class do we need? 2. Is our architecture cloud-native? 3. Which services and data flows are in the boundary? 4. Are we able to validate security outcomes continuously? 5. Do we have agency-specific requirements? 6. Are we already committed to a Rev5 assessment path? 7. Can our evidence system support current authorization data? If the answers are unclear, the problem is not the path. The problem is readiness. ## Key takeaways - 20x is the better path to evaluate for new cloud-native SaaS providers targeting Class A, B, or C. - Rev5 remains the right path for Class D, non-cloud-native services, and many existing authorizations. - Do not switch from Rev5 to 20x midstream without a specific reason. - Strong evidence operations help both paths. ## References - [FedRAMP Certification - Consolidated Rules for 2026 Public Preview](https://www.fedramp.gov/preview/2026/certification/) - [FedRAMP Rev5 Certification Rules](https://www.fedramp.gov/preview/2026/providers/rev5/) - [FedRAMP 20x Overview](https://www.fedramp.gov/20x/) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) ### FedRAMP 20x Class A, B, C, and D Explained - URL: https://boundera.io/blog/20x/fedramp-20x-classes-explained - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:12Z - Reading time: 6 minutes - Main question: How do FedRAMP 20x certification classes work? - TL;DR: Class A supports initial entry, Class B fits lighter use, Class C fits enterprise use, and Class D is not a 20x path in the current preview. - Excerpt: A practical explanation of FedRAMP certification classes and what they mean for 20x planning. ## FedRAMP classes are about certification depth FedRAMP's 2026 preview organizes certification around classes: A, B, C, and D. For teams coming from older FedRAMP language, this can be confusing. Class is not just a new name for Low, Moderate, and High. It is a way to describe the depth, expected use, and ongoing information burden of a certification profile. For FedRAMP 20x, the practical takeaway is simple: new cloud-native providers should understand Class A, B, and C. Class D is not a 20x path in the current preview. ## Class A Class A is for cloud services with mature security and compliance programs that want to enter the federal marketplace with a smaller initial information burden. Think of Class A as an initial entry point. It can help a provider establish a starting FedRAMP posture, but it is not the end state for services that become broadly adopted by agencies. Class A makes sense when: - The service is early in federal adoption. - The provider already has mature security practices. - Agencies need an initial level of certification data before broader use. - The provider expects to transition later to Class B or Class C. Class A should not be treated as "lightweight forever." If the product becomes important to agency operations, the certification class should mature with the use case. ## Class B Class B is for common, small-scale or light-use cloud services. It requires more information and ongoing reporting than Class A, but less than Class C. For SaaS providers with limited federal use cases, smaller blast radius, or lower agency dependency, Class B may be a reasonable target. Class B makes sense when: - The service supports lighter agency workflows. - An entire agency is unlikely to depend on the service for important operations. - The service has a smaller risk profile. - The provider can support ongoing reporting but does not need the heavier Class C posture. The key is honest use-case analysis. A provider should not choose Class B if agencies will use the product as an enterprise platform. ## Class C Class C is likely the main target for many enterprise SaaS providers. It applies to common enterprise services that may be used across an agency or may support important government services. Class C requires more information, stronger ongoing reporting, and a more mature evidence program. Class C makes sense when: - The product is an enterprise platform. - Agency-wide adoption is realistic. - The service supports important government workflows. - The provider needs a stronger posture for procurement and reuse. - The engineering team can support persistent validation and current authorization data. For many commercial SaaS teams, "FedRAMP 20x readiness" really means "Can we support a Class C operating model?" ## Class D Class D is for mission-critical or high-impact usage where failure could seriously affect agency operations, finances, or individuals. In the current [FedRAMP 2026 preview](/blog/20x/fedramp-20x-roadmap-2026), Class D is not a 20x path. Class D uses the agency certification path and remains a Rev5-oriented certification route. That means a provider targeting high-impact or mission-critical use should not assume 20x is available as the path today. The planning conversation should start with Rev5. ## How to choose Use this practical sequence: 1. Identify how agencies will actually use the service. 2. Determine whether the service is cloud-native and eligible for 20x. 3. Decide whether the expected use is initial entry, light use, enterprise use, or mission-critical use. 4. Map that to Class A, B, C, or D. 5. Confirm the path against current FedRAMP rules before making public claims. The mistake to avoid is choosing the lowest class because it feels easier. The right class should match the risk and dependency agencies will place on the service. ## What this means for product planning Class selection affects the whole operating model: - How much inventory detail you need - How complete [KSI validation](/blog/20x/fedramp-20x-ksi-validation) must be - How mature vulnerability detection and response needs to be - How much authorization data agencies will expect - How often validation runs - How much assessor review you should prepare for If your target is Class C, design for Class C from the beginning. Retrofitting persistent validation after the fact is much harder than building it into the [evidence system](/blog/20x/fedramp-20x-ksi-evidence-automation) early. ## Key takeaways - Class A is an initial entry point. - Class B fits lighter-use services. - Class C fits enterprise or important agency services. - Class D is mission-critical and not a 20x path in the current preview. - Class selection should follow real agency use, not convenience. ## References - [FedRAMP Certification - Consolidated Rules for 2026 Public Preview](https://www.fedramp.gov/preview/2026/certification/) - [Choosing a Certification Class](https://www.fedramp.gov/preview/2026/providers/start/class/) - [FedRAMP 20x Overview](https://www.fedramp.gov/20x/) ### What Is a 20x-Ready FedRAMP Trust Center? - URL: https://boundera.io/blog/20x/fedramp-compatible-trust-center - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:11Z - Reading time: 7 minutes - Main question: What should a 20x-ready FedRAMP trust center do? - TL;DR: A 20x trust center should support authorization data sharing, not just marketing collateral. It needs current data, access control, approval workflows, and audit logs. - Excerpt: Why a 20x-ready trust center should support authorization data sharing, access control, audit logging, and current package data. ## A 20x-ready trust center is not a marketing page Many SaaS companies already have a trust center. It usually includes security badges, compliance reports, privacy documents, subprocessor lists, and sometimes an NDA workflow. That is useful, but FedRAMP 20x pushes the idea further. A 20x-ready trust center or sharing mechanism should support authorization data sharing. Agencies and reviewers need access to current, relevant security information that helps them make risk and reuse decisions. That means the trust center becomes part of the compliance operating model. ## What authorization data sharing changes Authorization data sharing is about making the right FedRAMP certification data available to the right parties. For a provider, that means answering: - What data is shared? - Who can access it? - How is access approved? - How is access logged? - How is data kept current? - What happens when access is denied? - How do agencies find the latest package, evidence, inventory, validation, and vulnerability data? If the answer is "email us for a PDF," the workflow is probably not mature enough for 20x. ## What belongs in a 20x-ready trust center A practical 20x-ready trust center model includes: - Service description and boundary summary - Current certification status and target class - In-scope services and environments - Inherited services and external dependencies - [KSI evidence](/blog/20x/fedramp-20x-ksi-evidence-automation) and authorization data access - Validation summary - Vulnerability response summary - Security contact and FedRAMP Security Inbox information where applicable - Agency access request workflow - Access logs and approval history - Downloadable and machine-readable authorization data where appropriate The exact implementation can vary, but the trust center should be more than static collateral. ## Static trust pages create stale trust Static pages are easy to publish and easy to forget. The common failure pattern looks like this: 1. Security uploads documents. 2. Sales links prospects to the trust center. 3. Engineering changes the system. 4. Evidence and vulnerability posture change. 5. The trust center still shows old information. That model is not aligned with 20x. If authorization data is supposed to support current risk decisions, the sharing workflow needs a current source of truth. ## How trust center data should connect to the system The strongest model connects the trust center to: - Inventory and boundary records - KSI mappings - Persistent validation results - VDR status - Policies and human-process evidence - Change records - Package exports - Access controls and audit logs This does not mean every agency sees every raw signal. It means the provider can publish controlled, current views of the information reviewers need. ## Access control matters FedRAMP data sharing is not the same as making everything public. A serious authorization data sharing workflow should support: - Public summaries - Authenticated agency access - Role-based access to sensitive materials - Approval workflows - Expiration and revocation - Audit logging - Denial handling The access model should be clear enough that compliance, legal, sales, and security teams all know what can be shared and under what conditions. ## What agencies care about Agency stakeholders usually care less about a beautiful portal and more about decision-quality information. Many of them will first find a service through the [FedRAMP Marketplace](/blog/rev5/fedramp-marketplace-explained), then turn to the trust center for current detail. They need to know: - What service they are evaluating - Whether the service maps to their expected class and use case - Which parts of the system are in scope - What the current security posture is - Whether vulnerabilities are being handled - Whether [validation is current](/blog/20x/fedramp-20x-ksi-validation) - Whether exceptions exist - Who to contact for security issues Design the trust center around those questions. ## Common mistakes Avoid these: - Treating the trust center as a sales asset only - Posting stale reports without update dates - Sharing PDFs with no machine-readable source - Requiring manual email chains for every request - Failing to log access - Publishing status without scope - Separating trust center content from KSI evidence, authorization data, and VDR data These mistakes reduce trust instead of increasing it. ## How Boundera should position this Boundera should frame the trust center as the agency-facing surface of the compliance operating system. The value is not "host your documents." The value is: - Keep authorization data current - Control who can access sensitive evidence - Show validation status - Share KSI evidence and authorization data outputs - Tie vulnerability posture to agency-facing data - Reduce manual back-and-forth during review and reuse That is a much stronger product story for 20x buyers. ## Key takeaways - A 20x trust center should support authorization data sharing, not just marketing collateral. - Current boundary, validation, KSI, and VDR data should feed the sharing workflow. - Access control, approval, expiration, and audit logging are practical controls for a serious sharing workflow. - The trust center should help agencies make risk decisions with current information. ## References - [Authorization Data Sharing](https://www.fedramp.gov/docs/20x/authorization-data-sharing/) - [Authorization by FedRAMP KSI Theme](https://www.fedramp.gov/docs/20x/key-security-indicators/authorization-by-fedramp/) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [FedRAMP Certification - Consolidated Rules for 2026 Public Preview](https://www.fedramp.gov/preview/2026/certification/) ### VDR vs POA&M: How FedRAMP 20x Changes Vulnerability Management - URL: https://boundera.io/blog/20x/fedramp-20x-vdr-vs-poam - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:10Z - Reading time: 7 minutes - Main question: How is VDR different from traditional POA&M tracking? - TL;DR: VDR is a persistent vulnerability response process that connects findings, scope, exploitability, ownership, remediation, evidence, and authorization data. - Excerpt: How FedRAMP 20x shifts vulnerability work from periodic POA&M tracking toward persistent vulnerability detection and response. ## VDR changes the vulnerability operating model Traditional FedRAMP programs rely heavily on POA&M tracking as part of [continuous monitoring](/blog/rev5/fedramp-conmon-checklist). A POA&M is still a familiar way to record findings, milestones, owners, and remediation status. FedRAMP 20x pushes providers toward Vulnerability Detection and Response, or VDR. VDR is broader than a spreadsheet. It is a persistent process for discovering vulnerabilities, assessing their significance, responding promptly, and sharing current vulnerability posture as authorization data. The difference is not just format. It is tempo. ## POA&M thinking vs VDR thinking | Area | POA&M-centered model | VDR-centered model | | --- | --- | --- | | Primary artifact | Spreadsheet or tracker | Live vulnerability response data | | Cadence | Often periodic or assessment-driven | Persistent discovery and response | | Focus | Findings and milestones | Detection, exploitability, response, evidence | | Evidence | Status updates and closure proof | Current vulnerability signals and response history | | Review | Human inspection of open items | Review of vulnerability process and current authorization data | The POA&M mindset asks, "Did we update the tracker?" The VDR mindset asks, "Are we detecting, triaging, remediating, and reporting vulnerability risk fast enough to support authorization decisions?" ## What VDR typically includes A practical VDR workflow should include: - Vulnerability discovery from scanners, cloud services, suppliers, threat intelligence, and disclosure channels - Deduplication and asset matching - Severity and exploitability analysis - Internet reachability or exposure context where available - Ownership routing - Remediation due dates or expectations - Exception and risk-acceptance handling - Closure evidence - Reporting into authorization data Most organizations already have pieces of this. The gap is usually integration. Scanner findings live in one system, tickets in another, cloud inventory somewhere else, and compliance reporting in a spreadsheet. 20x readiness requires connecting those pieces. ## Why exploitability and reachability matter Not every vulnerability creates the same operational risk. A strong VDR process should distinguish: - A theoretical vulnerability in an unreachable component - A vulnerability in an internet-facing service - A vulnerability in a critical internal service - A vulnerability with known exploitation - A vulnerability with compensating controls That does not mean teams can ignore lower-priority issues. It means response should be informed by context, and the authorization data should explain that context clearly. ## How VDR connects to KSIs VDR is not separate from KSIs. Vulnerability posture can affect multiple KSI areas, including service configuration, monitoring, third-party resources, change management, and authorization reporting. For each vulnerability workflow, map: - Which resources are affected - Which KSI themes are implicated - Which evidence source detected the issue - Which owner is responsible - Which remediation action was taken - Which validation proves closure This creates a closed loop from finding to fix to evidence. The cadence of those proving checks follows the same [persistent validation schedule](/blog/20x/fedramp-20x-ksi-validation) as the rest of your KSIs. ## What a 20x-ready vulnerability record should include At minimum: - Finding ID - Source system - Affected resource - Boundary status - Vulnerability identifier where applicable - Severity - Exploitability context - Reachability or exposure context - Owner - Status - Due date or response expectation - Exception status - Closure evidence - Related KSI or authorization data link If a record cannot show scope, owner, status, and evidence, it will create review friction. ## Common mistakes Avoid these: - Treating VDR as a rebranded POA&M - Exporting scanner findings without ownership context - Ignoring asset scope, so out-of-boundary and in-boundary findings are mixed together - Closing tickets without evidence - Keeping exceptions open indefinitely - Separating vulnerability data from KSI validation - Reporting only monthly snapshots when the system changes continuously These are not just process flaws. They make the authorization data less trustworthy. ## How to start For the first VDR implementation sprint: 1. Connect your scanner and cloud inventory. 2. Match vulnerabilities to in-scope assets. 3. Add owner and service mapping. 4. Add exploitability and reachability context where available. 5. Create remediation routing. 6. Define exception rules and expiration. 7. Feed status into authorization data and [KSI evidence views](/blog/20x/fedramp-20x-ksi-evidence-automation). Once that loop works, expand coverage across suppliers, container images, dependencies, infrastructure-as-code, and runtime exposure. ## Key takeaways - VDR is a persistent vulnerability response process, not just a spreadsheet export. - The core shift is from periodic status tracking to current vulnerability authorization data. - Strong VDR records connect finding, asset, scope, owner, exploitability, remediation, and evidence. - VDR should feed KSI evidence views and authorization data sharing workflows. ## References - [Vulnerability Detection and Response](https://www.fedramp.gov/docs/20x/vulnerability-detection-and-response/) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [Authorization Data Sharing](https://www.fedramp.gov/docs/20x/authorization-data-sharing/) ### FedRAMP 20x KSI Evidence Package: What Should Be in the Export? - URL: https://boundera.io/blog/20x/fedramp-20x-ksi-package - Program: FedRAMP 20x - Category: Automation - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:09Z - Reading time: 8 minutes - Main question: What should a practical FedRAMP 20x KSI evidence export include? - TL;DR: A practical KSI evidence export can include boundary, inventory, KSI mappings, validation results, evidence references, VDR status, exceptions, and assessor-facing summaries. - Excerpt: A practical model for exporting FedRAMP 20x KSI evidence from current authorization data and validation results. ## The KSI evidence package is a practical implementation pattern FedRAMP's official docs talk about authorization data, KSI validation, persistent validation, VDR, and assessment outputs. "KSI evidence package" is practical product language: a way to describe the export or view that brings KSI mappings, validation results, evidence, and authorization data together for review. In FedRAMP 20x, those outputs should not be manually assembled binders that go stale the moment the environment changes. The better model is an evidence export [generated from current system data](/blog/20x/fedramp-20x-ksi-evidence-automation): boundary, inventory, KSI mappings, validation results, evidence references, vulnerability posture, exceptions, and assessor-facing summaries. That distinction matters. A static package can describe what a provider believes. A generated evidence export can show what the provider is currently validating. ## What the export should prove A useful KSI evidence export should help a reviewer answer four questions: 1. What is the cloud service offering? 2. Which security outcomes apply? 3. What evidence proves those outcomes? 4. How does the provider keep the evidence current? If the package cannot answer those questions clearly, the review will fall back into manual clarification loops. ## Core components ### Boundary and service description Start with the basics: - Service name and description - Authorization boundary - In-scope environments - In-scope cloud accounts, projects, subscriptions, clusters, and services - Major data flows - Identity and administrative paths - External dependencies and inherited services This section should be concise, but it cannot be vague. Every validation result depends on boundary clarity. ### Inventory A practical implementation includes current inventory for resources and processes that matter to the KSI map. Inventory fields often include: - Resource ID - Resource type - Environment - Owner - Scope status - Source system - Last-seen timestamp - Related KSI coverage An inventory that cannot show recency will create review risk. ### KSI applicability and mapping For each KSI, show whether it applies and why. Include: - KSI theme - KSI or assertion - Applicability decision - Security decision or goal - Affected resources or processes - Validation method - Evidence sources - Owner This section should be structured enough to export, filter, and review programmatically. ### Validation results Validation results are the core of the package. Each result should capture: - KSI reference - Resource or process tested - Expected state - Observed state - Result - Timestamp - Evidence reference - Validation method - Remediation owner when failed The export should make it easy to distinguish current passing results, failed results, exceptions, and items that are not applicable. The validation cadence behind those results is governed by [how often each check must run](/blog/20x/fedramp-20x-ksi-validation). ### Evidence references Evidence references should point back to authoritative systems rather than living only as detached files. Good references include: - Cloud API response IDs or snapshots - Log query links - CI/CD run IDs - Source control commit or policy links - Vulnerability finding IDs - Ticket IDs - Policy repository paths - Human review records The goal is traceability. Reviewers should be able to move from a KSI result to the evidence and from the evidence to the source system. ### VDR status Vulnerability Detection and Response belongs in the package because vulnerability posture is part of current authorization data. Include: - Open findings - Severity and exploitability context - Reachability where available - Owner - Due date or remediation expectation - Exception status - Evidence of closure This is where the old POA&M mindset needs to evolve. The evidence view should reflect current response posture, not just a periodic spreadsheet export. ### Exceptions and risk decisions Exceptions should be explicit. For each exception: - What failed - Why the exception exists - Who approved it - When it expires - What compensating control exists - Which agencies or reviewers need visibility Untracked exceptions are one of the fastest ways to erode trust in the package. ### Assessor-facing summaries The package or authorization-data view should include concise summaries that explain the validation approach for each KSI area when those summaries are needed for review. These should not replace evidence. They should orient the reviewer: - What the provider validates - How the validation runs - What evidence is produced - What coverage exists - What known limitations exist The best summaries are short, specific, and linked to validation data. ## Human-readable and machine-readable output A 20x evidence export should work for both humans and systems. Human-readable views help agencies, assessors, executives, and product security teams understand status quickly. Machine-readable outputs help [tools](/blog/20x/best-fedramp-compliance-tools-2026) ingest package data, compare changes, identify gaps, and keep authorization data current. Do not pick one at the expense of the other. Build a structured source of truth, then render it into the views different stakeholders need. ## Package anti-patterns Avoid these: - A PDF with no machine-readable source - A JSON file with no evidence traceability - A package generated once and never refreshed - Validation results without timestamps - KSI mappings that do not identify owners - Vulnerability status disconnected from VDR workflows - Screenshots with no source-system linkage - Exceptions without expiration dates These patterns make the package harder to review and harder to defend. ## How Boundera should help Boundera's product story should be simple: Connect evidence sources, map KSIs, run validation, identify gaps, track remediation, and export KSI evidence from current authorization data. The package is not the product. The operating model is the product. ## Key takeaways - A 20x evidence export should be generated from current evidence and validation data. - A practical export needs boundary, inventory, KSI mappings, validation results, evidence references, VDR status, exceptions, and summaries. - Human-readable and machine-readable views should come from the same source of truth. - A polished package without live evidence is not 20x readiness. ## References - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [Vulnerability Detection and Response](https://www.fedramp.gov/docs/20x/vulnerability-detection-and-response/) - [Authorization Data Sharing](https://www.fedramp.gov/docs/20x/authorization-data-sharing/) ### Persistent Validation in FedRAMP 20x: What the 3-Day Rule Means - URL: https://boundera.io/blog/20x/fedramp-20x-persistent-validation - Program: FedRAMP 20x - Category: Automation - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:08Z - Reading time: 7 minutes - Main question: How does persistent validation work in FedRAMP 20x? - TL;DR: Persistent validation requires repeatable evidence collection and validation across the boundary, with current guidance requiring Moderate machine validations at least every 3 days. - Excerpt: A practical guide to machine-based and non-machine-based validation under FedRAMP 20x. ## Persistent validation is the operating model Persistent validation is one of the clearest differences between FedRAMP 20x and traditional document-centered compliance. In a traditional model, a team gathers evidence for a review, remediates findings, and then tries to keep the package current. In 20x, the provider is expected to keep validating [Key Security Indicators](/blog/20x/ksi-vs-ssp) as part of the normal engineering workflow. That means validation is not an event. It is a system. ## The official cadence Current FedRAMP 20x persistent validation guidance sets different expectations for machine-based and non-machine-based resources. For machine-based resources: - Low: validation at least once every 7 days - Moderate: validation at least once every 3 days - High: FedRAMP notes that providers should plan for more frequent validation, but anticipated requirements have not been established in the current guidance For non-machine validation: - Validation processes must be completed at least once every 3 months The important point is not just the number of days. The important point is that the provider needs a repeatable validation program that covers the service boundary and produces current authorization data. ## What counts as a validation A validation is not just a scanner output. A useful validation result should include: - The KSI or assertion being checked - The resource or process in scope - The source system - The expected condition - The actual observed condition - The result - The timestamp - The evidence reference - The owner or remediation path if the check fails For example, "encryption enabled" is not enough. A stronger validation result says which storage resources were checked, what encryption setting was expected, what the cloud API returned, when the check ran, and which resources failed. ## Why screenshots do not scale Screenshots are weak persistent validation evidence because they are hard to diff, hard to query, hard to verify, and often disconnected from the current state of the system. They can still support human understanding, but they should not be the system of record. Better evidence comes from: - Cloud APIs - Identity provider APIs - CI/CD logs - Source control settings - Vulnerability scanners - SIEM and logging systems - Ticketing systems - Policy repositories The goal is not to remove human judgment. The goal is to make human judgment operate on current, structured evidence. ## How to design the validation loop A practical persistent validation loop has six parts. ### 1. Scope Start with the resources and processes inside the authorization boundary. If the boundary is wrong, validation coverage will be wrong. ### 2. Collect Pull evidence from authoritative systems. Prefer APIs and structured logs over manual exports. ### 3. Normalize Convert raw signals into a common evidence model: resource, timestamp, source, observed state, expected state, result, and evidence link. ### 4. Evaluate Run deterministic checks where possible. For human-process evidence, evaluate completion, recency, approval, and linkage to the relevant KSI. ### 5. Route Failed validations should create work. Route issues to the right owner with the failed assertion, affected resource, and recommended remediation. ### 6. Report Publish current validation status into authorization data, [KSI evidence views](/blog/20x/fedramp-20x-ksi-evidence-automation), and assessor-facing summaries. ## How assessors review persistent validation 20x changes [assessor](/blog/rev5/fedramp-3pao-assessors) work too. Assessors need to verify the underlying processes that produce validation results. They are not only checking whether a report says "pass." They need to understand whether the validation process is complete, accurate, reliable, and consistently producing the intended security outcome. Be ready to show: - How validation logic was defined - Which resources are covered - How missing resources are detected - How evidence is protected from tampering - How failed checks are remediated - How exceptions are approved - How stale evidence is identified - How human-process validations are documented If the process cannot be explained, the output will be hard to trust. ## Common implementation mistakes Avoid these patterns: - Running a scanner on a schedule and calling it persistent validation - Validating only production while ignoring CI/CD or identity paths that affect production - Tracking failures in Slack instead of a durable system - Allowing exceptions without owners and expiration dates - Treating human-process KSIs as static policy documents - Exporting a package without validation timestamps - Failing to map validation checks back to specific KSIs These issues are solvable, but they should be fixed before formal review. For a step-by-step on wiring the validation loop into CI/CD on AWS, see [FedRAMP continuous monitoring automation](/blog/20x/fedramp-continuous-monitoring-automation). ## A 30-day starting plan Start with the highest-signal validations: 1. Inventory coverage 2. MFA and privileged access 3. Logging enabled across in-scope services 4. Encryption for storage and transport paths 5. Public exposure and network ingress 6. Vulnerability detection and remediation ownership 7. CI/CD change traceability Once those are working, expand into the full KSI map. ## Key takeaways - Persistent validation is a repeatable operating program, not a one-time export. - Machine-based validations need current, structured evidence and clear pass/fail logic. - Non-machine validations still need cadence, ownership, and evidence. - Assessors will care about the process that creates validation results. - The strongest KSI evidence views are generated from persistent validation rather than assembled manually. ## References - [Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [FedRAMP 20x Overview](https://www.fedramp.gov/20x/) ### What Are FedRAMP 20x KSIs? A Practical Guide for CSPs - URL: https://boundera.io/blog/20x/fedramp-20x-ksi-guide - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:07Z - Reading time: 8 minutes - Main question: What are FedRAMP 20x Key Security Indicators and how should CSPs implement them? - TL;DR: KSIs are security outcomes, not a shorter checklist. Each KSI needs applicability, evidence, validation method, cadence, owner, and a failure path. - Excerpt: How to understand, map, validate, and evidence FedRAMP 20x Key Security Indicators. ## KSIs are the heart of FedRAMP 20x Key Security Indicators, or KSIs, are the main way FedRAMP 20x organizes security expectations for cloud-native services. The easiest mistake is to think of KSIs as a shorter control checklist. That framing is wrong. KSIs are closer to security outcomes that need to be implemented, validated, evidenced, and monitored across the cloud service offering. In Rev5, teams often start with a [control baseline and write how the system implements each control](/blog/20x/ksi-vs-ssp). In 20x, teams start with a cloud service boundary and ask: "Which security outcomes must be true, how do we know they are true, and how often do we validate that?" ## The KSI themes FedRAMP groups KSIs into themes so providers and reviewers can reason about related security outcomes together. FedRAMP currently organizes Key Security Indicators into **11 themes**: - **Authorization by FedRAMP:** government-specific authorization, reporting, and sharing requirements - **Cloud Native Architecture:** secure cloud architecture, isolation, exposure reduction, and boundary clarity - **Identity and Access Management:** authentication, authorization, privileged access, service accounts, and least privilege - **Service Configuration:** secure configuration, encryption, and service-level hardening - **Monitoring, Logging, and Auditing:** audit trails, monitoring coverage, alerting, and log integrity - **Change Management:** deployment discipline, change traceability, and controlled release workflows - **Policy and Inventory:** current inventory, governance, policy coverage, and scope awareness - **Cybersecurity Education:** training and security awareness processes - **Incident Response:** response procedures, testing, lessons learned, and communications - **Supply Chain Risk:** understanding, monitoring, and managing risk from third-party information resources, suppliers, and external dependencies - **Recovery Planning:** backups, restoration, resilience, and continuity planning Not every theme is validated the same way. Some signals are machine-based. Some are human-process evidence. Many are hybrid. ## Machine, non-machine, and hybrid validation The most useful way to operationalize KSIs is to classify each validation method. **Machine-based validation** checks a technical state directly. Examples include whether cloud logging is enabled, whether storage is encrypted, whether a public endpoint is exposed, or whether privileged access requires the expected identity control. **Non-machine validation** checks a human process or organizational activity. Examples include training reviews, incident exercises, policy approvals, or executive reviews. **Hybrid validation** combines both. A vulnerability process might need scanner data, exploitability context, ticket ownership, SLA tracking, and documented exception handling. This classification matters because [persistent validation cadence differs for machine-based and non-machine-based resources](/blog/20x/fedramp-20x-ksi-validation). It also affects how assessors review the reliability of the validation process. ## How to map KSIs to your system Start with a simple table for each KSI: | Field | What to capture | | --- | --- | | KSI | The indicator or requirement being addressed | | Applicability | Whether it applies to the service boundary | | Security decision | The outcome or standard the provider has chosen | | Resources | The in-scope systems, services, or processes affected | | Evidence source | API, log, scanner, ticket, policy, repository, or review record | | Validation method | Machine-based, non-machine, or hybrid | | Cadence | How often validation runs | | Owner | Team responsible for the outcome | | Failure path | What happens when validation fails | Do not start with prose. Start with mapping. Prose can be generated later from accurate structure, but structure cannot be recovered from vague prose. ## What good KSI evidence looks like Good KSI evidence is traceable. For each result, a reviewer should be able to see: - What was checked - Which resource or process was checked - When it was checked - Which source system produced the evidence - What the expected condition was - What the actual result was - Whether the result passed, failed, was partial, or was not applicable - Who owns remediation if the result failed Raw evidence without context creates review work. Context without raw evidence creates trust problems. The goal is both. ## Where teams usually struggle Most early KSI gaps are not exotic. They usually come from: - Poor boundary definition - Incomplete inventory - Evidence that exists but is not tied to specific KSIs - Validation checks that cover only part of the environment - Human-process evidence that is stored in documents but not tracked as current evidence - Vulnerability data that is disconnected from authorization data - Exceptions that are known informally but not captured cleanly The fix is not to write more. The fix is to make the system of record more complete. ## A practical first pass For a first 30-day KSI mapping sprint: 1. Define the boundary. 2. Build the resource inventory. 3. Map KSI themes to system owners. 4. Identify the evidence source for each KSI. 5. Mark each validation as machine, non-machine, or hybrid. 6. Run a gap review. 7. Prioritize IAM, logging, service configuration, vulnerability, and inventory gaps first. Those areas usually unlock the most downstream progress. ## How this becomes KSI evidence for review FedRAMP's official model centers on authorization data and KSI validation. In practice, teams often need an export or view that packages KSI evidence for reviewers. That output should not be a manually written report. It should be [generated from](/blog/20x/fedramp-20x-ksi-evidence-automation): - KSI mappings - Validation results - Evidence references - Inventory - Vulnerability response data - Exceptions and remediation status - Assessor-facing summaries If the KSI map is accurate, the package becomes easier to generate and easier to defend. If the KSI map is weak, the package will be hard to trust no matter how polished it looks. ## Key takeaways - KSIs are security outcomes that need evidence and validation. - Treat each KSI as a mapped workflow: applicability, resource, evidence, validation, cadence, owner, and failure path. - Machine-based, non-machine, and hybrid validations should be handled differently. - The strongest KSI evidence views are generated from current mappings and validation results. ## References - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [Authorization by FedRAMP KSI Theme](https://www.fedramp.gov/docs/20x/key-security-indicators/authorization-by-fedramp/) - [Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [FedRAMP 20x Overview](https://www.fedramp.gov/20x/) ### FedRAMP 20x vs Rev5: What Actually Changes for CSPs - URL: https://boundera.io/blog/20x/fedramp-20x-vs-rev5 - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2026-05-24T12:00:00.000Z - Updated: 2026-06-17T20:43:06Z - Reading time: 8 minutes - Main question: What is the real difference between FedRAMP 20x and Rev5? - TL;DR: Rev5 is a document-heavy authorization model. 20x is an evidence-driven certification model built around KSIs, persistent validation, VDR, and current authorization data. - Excerpt: A practical comparison of the Rev5 and 20x operating models, including documentation, KSIs, validation, VDR, and authorization data. ## The short version FedRAMP Rev5 and FedRAMP 20x are not just two names for the same authorization process. They represent two different operating models. Rev5 is the traditional FedRAMP path built around NIST SP 800-53 Rev. 5 controls, large documentation packages, independent assessment, agency review, continuous monitoring, and a long-running authorization lifecycle. 20x is the cloud-native path built around current authorization data, Key Security Indicators (KSIs), persistent validation, vulnerability detection and response, and repeatable evidence sharing. Both matter. Rev5 remains important for existing authorizations, non-cloud-native services, and Class D. But for many new commercial SaaS providers, 20x is the path to design toward. ## What changes structurally The biggest change is where FedRAMP expects the truth to live. In Rev5, the system package is the center of gravity. Teams build and maintain a [System Security Plan](/blog/20x/ksi-vs-ssp), assessment artifacts, control implementation narratives, diagrams, policies, procedures, and POA&M tracking. The package is reviewed heavily by humans, and ongoing monitoring updates the package over time. In 20x, the operating system is the center of gravity. The package should reflect current system state, validation results, vulnerability posture, inventory, authorization data, and evidence signals. The output still matters, but the machinery that generates it matters more. That is why a 20x program cannot be reduced to "export a JSON file." If the evidence pipeline is stale, the package is stale. ## Rev5 is control-centered; 20x is outcome-centered Rev5 asks: "How does this system implement the required controls?" 20x asks: "Can this system continuously demonstrate that important security outcomes are actually happening?" That difference changes the work: | Area | Rev5 | 20x | | --- | --- | --- | | Core model | Control implementation documentation | KSI outcomes and validation | | Evidence | Collected for assessment and continuous monitoring | Produced and refreshed through persistent validation | | Package | SSP, assessment artifacts, POA&M, supporting docs | Authorization data, KSI validation results, evidence views, VDR data | | Review | Heavy human review of narratives and artifacts | Review of current data and validation processes | | Vulnerabilities | POA&M-centered tracking | VDR-centered detection and response | | Sharing | Package access and reuse workflows | Authorization data sharing and trust center-style access | The practical consequence: Rev5 rewards strong documentation discipline. 20x rewards strong engineering telemetry and evidence operations. ## Rev5 still matters It would be a mistake to treat Rev5 as obsolete. Rev5 remains relevant when: - You already have a Rev5 authorization to maintain. - You are deep into an active Rev5 authorization effort. - You operate non-cloud-native infrastructure. - You need Class D certification. - Your agency customer requires the traditional agency certification route. FedRAMP's [2026 preview](/blog/20x/fedramp-20x-roadmap-2026) explicitly keeps Rev5 in the operating environment. The strategy should not be "delete Rev5." The strategy should be "know which path your service belongs on and avoid building Rev5-only habits into a 20x future." ## What 20x changes for engineering teams 20x pushes compliance into the engineering workflow. Engineering teams need to help define: - Which resources are inside the authorization boundary - Which cloud and identity configurations prove KSI outcomes - Which validation checks run automatically - Which failures block deployment, create tickets, or require exceptions - Which logs and evidence sources are authoritative - Which vulnerability signals flow into VDR reporting - How changes affect current authorization data This is not just a GRC team exercise. If infrastructure, identity, logging, deployment, and vulnerability data live with engineering, then 20x readiness lives with engineering too. ## What 20x changes for compliance teams Compliance teams move from document ownership to system-of-record ownership. That means: - Mapping KSIs to evidence sources instead of only writing control narratives - Tracking validation coverage across the boundary - Knowing which evidence is machine-based, non-machine-based, or hybrid - Reviewing failed validation assertions with technical owners - Maintaining authorization data sharing workflows - Explaining the validation process to assessors and agencies The compliance function becomes more operational. The question is no longer "Do we have the document?" It is "Can we prove this outcome from current evidence?" ## How to decide which path to pursue Use this decision path: 1. If the service needs Class D, plan around Rev5. 2. If the service is not cloud-native or depends on self-managed physical infrastructure, plan around Rev5. 3. If the service is a new cloud-native SaaS built on FedRAMP Certified infrastructure or platforms, evaluate 20x first. 4. If the service is already far into Rev5, finish the current path unless there is a strong reason to change. 5. If you are unsure, design the evidence system to support both: structured inventory, source-linked evidence, vulnerability workflows, and machine-readable package data. The last point matters. Even Rev5 is moving toward more machine-readable package expectations. Building evidence discipline now reduces migration pain later. ## Common mistake: treating 20x as a shortcut 20x can reduce waste, but it is not standards-lite. The hard parts move: - Less manual package assembly, more evidence engineering - Less screenshot collection, more API-driven validation - Less annual scramble, more persistent operation - Less static POA&M hygiene, more live vulnerability response - Less document review alone, more validation process review For a mature SaaS team, that shift is good. For a team with unclear ownership, weak inventory, inconsistent logging, and manual vulnerability response, 20x will expose the gaps quickly. ## How Boundera should frame the difference The clean positioning is: Rev5 is document-heavy authorization. 20x is evidence-driven certification. Boundera helps teams cross that gap by connecting evidence sources, mapping KSIs, validating outcomes, identifying gaps, and exporting KSI evidence from current system data. That is a stronger message than "faster FedRAMP." The buyer does not just need speed. They need a compliance operating system that can keep up with production. ## Key takeaways - Rev5 and 20x are different operating models, not just different package names. - Rev5 remains important for existing systems, non-cloud-native systems, and Class D. - 20x is the better default to evaluate for new cloud-native SaaS providers targeting Class A, B, or C. - The biggest 20x shift is persistent evidence: current inventory, [KSI validation](/blog/20x/fedramp-20x-ksi-validation), VDR, and authorization data sharing. - Teams should invest in evidence pipelines and validation workflows before worrying about final package polish. ## References - [FedRAMP 20x Overview](https://www.fedramp.gov/20x/) - [FedRAMP Certification - Consolidated Rules for 2026 Public Preview](https://www.fedramp.gov/preview/2026/certification/) - [FedRAMP Rev5 Certification Rules](https://www.fedramp.gov/preview/2026/providers/rev5/) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) ### How to Get FedRAMP 20x Certified: A Step-by-Step Guide for CSPs - URL: https://boundera.io/blog/20x/how-to-get-fedramp-20x-certified - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2026-05-23T12:00:00.000Z - Updated: 2026-06-17T20:43:05Z - Reading time: 13 minutes - Main question: How do CSPs actually get ready for FedRAMP 20x certification? - TL;DR: FedRAMP 20x readiness starts with eligibility, class selection, boundary definition, KSI mapping, evidence sources, persistent validation, VDR, authorization data sharing, and current KSI evidence exports. - Excerpt: A practical, official-source-grounded roadmap for cloud service providers preparing for FedRAMP 20x. ## Start with the current FedRAMP 20x framing FedRAMP 20x is not just a faster version of the old FedRAMP process. It is a cloud-native certification model built around current authorization data, Key Security Indicators (KSIs), persistent validation, and evidence that can be reviewed repeatedly instead of reconstructed during a documentation sprint. The current FedRAMP Consolidated Rules preview uses **FedRAMP Certification** as the umbrella term, with two certification types: **FedRAMP Rev5** and **FedRAMP 20x**. That matters because older market content may still describe 20x as "validated" or talk about older pilot terminology. Use official FedRAMP pages as the source of truth before making roadmap or sales commitments. Here is the practical path a cloud service provider should build toward. ## Step 1: Confirm that 20x is the right path FedRAMP 20x is designed for cloud-native commercial cloud services that are built on FedRAMP Certified infrastructure and platforms. It is the better starting point for [many new SaaS providers](/blog/20x/fedramp-for-startups), but it is not the right path for every system. Use 20x when: - Your service is cloud-native and runs on inherited FedRAMP Certified infrastructure or platform services. - Your team can maintain current system inventory, security evidence, and validation results. - You are targeting Class A, Class B, or Class C certification. - Your engineering and compliance teams can support automated or repeatable validation workflows. Use Rev5 or stay close to a Rev5 strategy when: - You operate physical datacenters or non-cloud-native infrastructure. - You need Class D certification. - You are already deep into an existing Rev5 authorization path and changing lanes would create more risk than benefit. - Your agency customer specifically requires the traditional agency certification path. The decision should happen before package work begins. If you pick 20x, you are not just choosing a different export format. You are choosing an operating model where evidence, validation, vulnerability response, and authorization data stay current. ## Step 2: Choose the right certification class FedRAMP's [2026 preview](/blog/20x/fedramp-20x-roadmap-2026) organizes certification around classes instead of treating every cloud service as the same level of operational burden. - **Class A** is for mature services entering the federal marketplace with a smaller amount of information and initial ongoing reporting. - **Class B** is for common small-scale or light-use services. - **Class C** is for common enterprise services and is likely the most important target for many SaaS companies. - **Class D** is for mission-critical or high-impact usage and is not a 20x path in the current preview. For most SaaS companies thinking about 20x, the working question is usually: "Are we preparing for Class B or Class C?" Class C requires more complete operating evidence, stronger ongoing reporting, and a more mature validation program. Do not choose the lowest class just because it sounds easier. Choose the class that matches how federal agencies will actually use the service. ## Step 3: Define the authorization boundary Before you map KSIs or export a package, define what is in scope. At minimum, document: - Cloud accounts, subscriptions, projects, clusters, and environments in scope - Application services and APIs in scope - Data stores, queues, logs, object storage, and backup locations - Identity providers, privileged roles, service accounts, and administrative paths - CI/CD systems and repositories that can affect production - Third-party services, external APIs, and inherited FedRAMP services - Network paths, ingress points, egress paths, and management interfaces This is where many teams underinvest. A weak boundary creates weak evidence. If nobody agrees which resources are inside the cloud service offering, your KSI validation results will be impossible to trust. The boundary should be understandable by both engineering and compliance. Engineers should be able to look at a resource and know whether it is in scope. Reviewers should be able to trace evidence back to the relevant part of the system. ## Step 4: Build an inventory that can stay current FedRAMP 20x depends on current authorization data. That means static spreadsheets and one-time asset exports are not enough. Start with a living inventory for: - Machine-based resources such as compute, containers, serverless functions, databases, storage, network components, and identity resources - Non-machine-based resources such as policies, procedures, reviews, training, incident exercises, and human approval workflows - External dependencies such as third-party APIs, managed services, libraries, and supplier-controlled components - Evidence sources such as cloud APIs, SIEMs, vulnerability scanners, ticketing systems, CI/CD systems, source control, and policy repositories Each inventory item should have an owner, scope status, source system, last-seen timestamp, and relationship to the service boundary. Without this, persistent validation becomes a pile of disconnected checks. ## Step 5: Map your system to the KSI themes 20x centers around Key Security Indicators. KSIs are not just a shorter checklist. They describe security outcomes that need supporting decisions, implementation details, validation logic, and evidence. Start by mapping your system across the major KSI themes: - Authorization by FedRAMP - Cloud Native Architecture - Identity and Access Management - Service Configuration - Monitoring, Logging, and Auditing - Change Management - Policy and Inventory - Cybersecurity Education - Incident Response - Third-Party Resources - Recovery Planning For each KSI, capture: - The security decision or goal - The systems and resources affected - The validation method - Whether the validation is machine-based, non-machine-based, or hybrid - The evidence source - The expected cadence - The owner - The remediation path when validation fails This turns 20x from a policy exercise into an engineering workflow. ## Step 6: Connect evidence sources The difference between a 20x-ready program and a document-generation exercise is evidence quality. Connect evidence sources where the truth already lives: - Cloud configuration APIs for network, storage, compute, encryption, and logging settings - Identity provider APIs for MFA, privileged access, groups, service accounts, and session controls - CI/CD systems for deployment history, approval gates, test results, and infrastructure changes - Source control for infrastructure-as-code, branch protection, and code review records - Vulnerability scanners for findings, severity, reachability, exploitability, and remediation status - SIEM or logging platforms for audit trails, detection coverage, and alert handling - Ticketing systems for change management, incident response, and remediation ownership - Policy repositories for human-process evidence and procedural approvals Evidence should include what was checked, when it was checked, which resource it applies to, what result was produced, and where the raw source can be reviewed. Screenshots can help a human understand context, but they should not be the foundation of a 20x evidence program. ## Step 7: Implement persistent validation Persistent validation is one of the biggest operational changes in 20x. For machine-based resources, the current FedRAMP 20x [persistent validation guidance requires validation at least every **7 days for Low** and at least every **3 days for Moderate**](/blog/20x/fedramp-20x-ksi-validation). Non-machine validation must be completed at least every **3 months**. In practice, your validation program should answer: - Which KSIs are validated automatically? - Which KSIs require human or process evidence? - Which resources are covered by each validation? - How often does each validation run? - How are failures triaged? - How are exceptions documented? - How does a reviewer know the validation process itself is reliable? Do not treat this as "run a scanner every few days." A scanner output is only one signal. Persistent validation should produce a defensible result: pass, fail, partial, not applicable, or exception, with evidence attached. ## Step 8: Remediate KSI gaps before packaging Once validation starts running, expect gaps. Common early gaps include: - Incomplete inventory inside the boundary - MFA or privileged access exceptions that were not documented - Logging that exists but is not complete across all in-scope services - Encryption settings that are inconsistent across environments - Vulnerability findings without owner, due date, or exploitability context - CI/CD changes that are approved in practice but not evidenced consistently - Third-party dependencies that are not tied back to supplier risk evidence The best remediation workflow is assertion-level. Instead of saying "IAM is weak," your system should identify the exact failed KSI assertion, affected resource, missing evidence, likely owner, and recommended fix. This is where a platform like Boundera should help: not by producing prettier documentation, but by turning failed validations into work that engineering can actually close. ## Step 9: Build the VDR workflow FedRAMP 20x moves vulnerability management toward persistent Vulnerability Detection and Response (VDR). The important shift is that vulnerability posture becomes part of current authorization data, not just a monthly spreadsheet artifact. Your VDR workflow should cover: - Continuous vulnerability discovery from scanners, cloud services, suppliers, and disclosure channels - Severity, reachability, exploitability, and impact analysis - Ownership and remediation routing - Exception and risk-acceptance documentation - Evidence that the vulnerability was fixed or mitigated - Reporting that can be shared as authorization data Do not wait until the package is ready to design this. If VDR is not wired into the engineering workflow, your authorization data and evidence views will look current only on export day. ## Step 10: Prepare authorization data sharing 20x assumes relevant parties can access current authorization data. That makes your trust center or sharing mechanism more than a marketing page. A 20x-ready sharing model should handle: - Who can access authorization data - What data is shared - How requests are approved or denied - How access is logged - How current package data is refreshed - How agencies or reviewers find the latest inventory, validation results, vulnerabilities, and supporting evidence This is also a sales issue. Federal buyers do not just want to know that you have a security page. They need enough current detail to make a reuse or risk decision. ## Step 11: Prepare authorization data and KSI evidence exports FedRAMP's official language is centered on authorization data, KSI validation, persistent validation, VDR, and assessor-facing outputs. In Boundera product language, we use "KSI evidence package" to describe a practical export that brings those materials together for review. A practical 20x evidence export should include: - Boundary and service description - KSI mapping and applicability decisions - Validation results by KSI - Evidence references and source systems - Validation cadence and last-run timestamps - Inventory and dependency data - VDR status and vulnerability response evidence - Exceptions, risk decisions, and remediation plans - Assessor-facing summaries where required - Machine-readable artifacts where applicable The output should be explainable to humans and usable by machines. If a reviewer asks why a KSI passed, the export should trace from the result to the evidence and from the evidence to the source system. ## Step 12: Prepare for independent assessment Under 20x, [assessors](/blog/rev5/fedramp-3pao-assessors) do not only review the final output. They need to verify the processes that generate the output. Be ready to show: - How validation logic works - How evidence is collected and protected - How coverage is determined across the boundary - How failures are detected and routed - How exceptions are approved - How stale evidence is identified - How changes affect validation results - How human-process KSIs are reviewed This is a major difference from a document-heavy Rev5 mindset. The package matters, but the machinery behind the package matters more. ## Step 13: Maintain certification continuously FedRAMP 20x does not end when the package is submitted. After certification, keep the same operating loop running: - Refresh inventory - Run persistent validation - Remediate failed KSI assertions - Keep VDR current - Share current authorization data - Track significant changes - Maintain incident and security inbox workflows - Update evidence when the system changes - Prepare for recurring independent validation The winning model is boring in the best way: evidence stays current because the system keeps producing it. ## A simple implementation roadmap ### Days 0-30: Scope and evidence foundations - Confirm 20x eligibility and target class - Define the authorization boundary - Build the initial inventory - Identify KSI owners - Connect the first evidence sources: cloud, identity, source control, CI/CD, vulnerability scanner ### Days 31-60: KSI mapping and validation - Map KSIs to systems, evidence sources, and validation methods - Classify validations as machine-based, non-machine-based, or hybrid - Start running validation on a schedule - Create failure routing and remediation workflows - Establish exception handling ### Days 61-90: Package and assessment readiness - Generate a draft authorization data and KSI evidence export - Review evidence traceability - Harden VDR reporting - Prepare authorization data sharing - Walk through the validation process with assessor-style questions - Fix the gaps before formal review ## What to validate before publishing your own 20x plan FedRAMP 20x is moving quickly, so every public guide should be checked against official sources before publication. Use this lightweight checklist: | Claim | Official source to check | How to word it safely | | --- | --- | --- | | 20x is for cloud-native commercial services | FedRAMP 20x overview and 2026 certification preview | "FedRAMP describes 20x as a cloud-native certification process..." | | Class A/B/C/D rules | 2026 certification preview | "In the current preview..." | | Class D availability | 2026 certification preview | "Class D is not a 20x path in the current preview." | | KSI themes and applicability | FedRAMP KSI docs | "KSIs apply to 20x offerings and should be addressed across the assessment scope." | | Persistent validation cadence | FedRAMP PVA docs | "Current guidance requires..." | | VDR obligations | FedRAMP VDR docs | "VDR requires persistent vulnerability detection and response..." | | Authorization data sharing | FedRAMP ADS docs | "20x programs need a way to share current authorization data..." | This avoids the biggest content risk: repeating old pilot language after FedRAMP has updated its terminology. ## Key takeaways - FedRAMP 20x is an operating model, not just a faster paperwork path. - The work starts with boundary, inventory, KSI mapping, evidence sources, and persistent validation. - A 20x evidence export should be generated from current evidence and validation results, not manually assembled as a static report. - VDR and authorization data sharing need to be designed early, not bolted on later. - Before publishing or committing to a roadmap, validate terminology and class rules against official FedRAMP pages. ## References - [FedRAMP 20x Overview](https://www.fedramp.gov/20x/) - [FedRAMP Certification - Consolidated Rules for 2026 Public Preview](https://www.fedramp.gov/preview/2026/certification/) - [FedRAMP Rev5 Certification Rules](https://www.fedramp.gov/preview/2026/providers/rev5/) - [FedRAMP 20x Key Security Indicators](https://www.fedramp.gov/docs/20x/key-security-indicators/) - [Persistent Validation and Assessment](https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/) - [Vulnerability Detection and Response](https://www.fedramp.gov/docs/20x/vulnerability-detection-and-response/) - [Authorization Data Sharing](https://www.fedramp.gov/docs/20x/authorization-data-sharing/) ### FedRAMP Authorization Guide (Pillar): From Readiness to ATO + Staying Authorized - URL: https://boundera.io/blog/rev5/fedramp-authorization-guide-pillar - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2025-05-21T12:00:00.000Z - Updated: 2026-06-17T20:43:04Z - Reading time: 14 minutes - Main question: What does the full FedRAMP journey look like end to end? - TL;DR: The real work spans readiness, package development, assessment, remediation, authorization, and continuous monitoring. Each stage compounds the next. - Excerpt: A pillar page that maps the major FedRAMP stages and links the surrounding guidance together. ## FedRAMP Authorization Guide: From Readiness to ATO + Staying Authorized If you’re a cloud service provider (CSP) trying to sell to U.S. federal agencies, FedRAMP is the path. But “getting FedRAMP” is not one thing. It’s a sequence of decisions, documents, assessments, and then an operational cadence that never really ends. This guide is written to be practical: what to do first, what documents matter, how to avoid delays, and how to keep your ATO active once you finally get it. * * * ## Quick Definitions (so the rest makes sense) - **CSP**: Cloud Service Provider (you). - **CSO**: Cloud Service Offering (the specific product/system boundary being authorized). - **ATO**: Authority to Operate (the approval to run for an agency under defined risk conditions). - **AO**: Authorizing Official (the risk decision-maker at an agency). - **[3PAO](/blog/rev5/fedramp-3pao-assessors)**: Third-Party Assessment Organization (the independent assessor). - **SSP**: System Security Plan (the “how we implement controls” backbone). - **SAP**: Security Assessment Plan (how the 3PAO will test controls). - **SAR**: Security Assessment Report (what the 3PAO found). - **POA&M**: Plan of Action & Milestones (open risks + remediation plan). - **ConMon**: Continuous Monitoring (the after-ATO operating rhythm). * * * ## The 4 Decisions That Shape Your Entire FedRAMP Journey ### 1) What exactly is “in scope”? FedRAMP is scoped to a specific system boundary. If your boundary is fuzzy, everything else becomes painful: inventories don’t match diagrams, evidence doesn’t map cleanly, assessors can’t test consistently, and reviewers lose confidence. Your scope should cleanly answer: - What customer data enters the system? - Where is it processed, stored, and logged? - What accounts and identity systems administer it? - What supporting services are in-boundary vs. out-of-boundary? ### 2) Which baseline / impact level are you targeting? FedRAMP baselines align to NIST 800-53. Your target depends on the sensitivity and intended federal use. Don’t pick a baseline because it “sounds impressive.” Pick it because it matches real customer needs and your architecture can sustain it. **Practical tip:** If you’re a SaaS product, your baseline decision will also drive how you write customer responsibility and shared controls. That becomes a big deal in both the SSP and ConMon. ### 3) Which authorization path are you pursuing? - **Agency authorization:** The most common path—an agency AO sponsors/authorizes your CSO. - **JAB path:** More centralized, reuse-focused, and typically higher scrutiny. Even if you eventually want broad reuse, many teams start with an agency ATO because it’s the most realistic entry point. ### 4) How will you operate after ATO? Your first FedRAMP authorization is a project. ConMon is a lifestyle. If you don’t set up operational ownership early (security + engineering + product), you’ll “get the ATO” and then bleed time every month after. * * * ## The End-to-End FedRAMP Flow (What Happens in Real Life) ### Step 1: Readiness (before you pay a 3PAO to test) You want to enter assessment with a stable boundary, stable logging, stable identity story, and controls that are actually implemented. Readiness is where you prevent rework. **Readiness checklist:** - Architecture diagram + data flow diagram that match your reality - Inventory that matches what’s deployed (not what you wish was deployed) - Logging and alerting you can demonstrate (not just “enabled”) - Vulnerability scanning + patch cadence defined and followed - Policies and procedures that match how your team actually works ### Step 2: Build the Security Package (SSP is the center of gravity) Your SSP is where everything meets: scope, architecture, control implementation details, roles/responsibilities, and how evidence ties back to controls. In practice, most schedule slip happens because SSP content is vague, inconsistent, or not backed by evidence. **What reviewers and assessors want to see in control statements:** - **What** is implemented (specific tools and configurations) - **Where** it applies (system boundary + components) - **Who** owns it (roles, not just “the team”) - **How** it’s enforced and monitored - **Evidence** that proves it (screenshots, exports, logs, policies, tickets) **Reality check:** FedRAMP failures are rarely about “missing security.” They’re often about weak documentation quality and weak traceability from controls → evidence → implementation reality. ### Step 3: 3PAO Assessment (SAP → testing → SAR) The 3PAO assesses your controls against the baseline and produces the official assessment artifacts. This is where “we have a process” becomes “prove it, with artifacts.” - **SAP:** how the assessment will be performed, scope, and methods - **Testing:** interviews, evidence review, technical validation, sampling - **SAR:** results + findings that will drive risk decisions and POA&M contents ### Step 4: POA&M (the part everyone underestimates) Your POA&M is not a formality. It’s the live risk register tied to assessment results. If the POA&M doesn’t line up with assessment findings, or if dates/owners are fantasy, reviewers will slow you down. **POA&M hygiene rules that keep you out of trouble:** - Every risk in the assessment results should map to a POA&M item - Dates should reflect real engineering capacity - Owners should be accountable roles - Closure should require evidence, not optimism ### Step 5: Authorization Decision (ATO) An AO makes the risk decision based on the security package, assessment results, and your remediation plan. In many cases, authorization is possible even with open items—if the risk is acceptable and the POA&M is credible. * * * ## After ATO: Continuous Monitoring (ConMon) Is Where Most Teams Feel the Pain Once authorized, you must [continuously prove](/blog/rev5/fedramp-conmon-checklist) that your system is still operating within risk tolerance: patching, scanning, reporting, change control, incident response, and ongoing evidence. **ConMon in plain language:** “Show your work, every month. And don’t surprise anyone with changes.” ### What ConMon typically includes - Recurring vulnerability scanning + results handling - POA&M updates (open, aging, closure evidence) - Inventory maintenance (keep it aligned to reality) - Incident reporting and response execution - Significant change control (SCRs) before changes land - Ongoing meetings/reviews with stakeholders **Good operating model:** Treat ConMon like a product sprint. One owner, one cadence, one dashboard, and the evidence is produced as a byproduct of normal operations—not a monthly fire drill. * * * ## Where Automation and OSCAL Actually Help (Without the Hype) Automation doesn’t “do FedRAMP for you.” But it can eliminate the worst parts: manual evidence collection, copy-paste SSP updates, and losing traceability across tools. ### High-value automation targets - **Evidence collection:** pull from AWS/Azure/GCP, IAM/IdP, SIEM, ticketing, CI/CD, config tools - **Control-to-evidence mapping:** keep a living map so audits don’t become scavenger hunts - **Package generation:** draft SSP sections and appendices using real system facts (then review) - **ConMon reporting:** generate recurring deliverables from live data sources ### OSCAL (why it matters) [OSCAL](/blog/20x/oscal-for-fedramp-guide) is a machine-readable way to represent security content like controls, baselines, SSPs, and assessment results. If your goal is repeatable automation and faster reuse, OSCAL becomes a serious advantage. * * * ## How Boundera Fits (If You Want to Move Faster With Less Manual Work) Boundera is built for teams that don’t want a documentation marathon: - Connect your cloud + tooling and pull evidence automatically - Map evidence to control families so traceability is always available - Generate draft package content (SSP-style narratives) from real system context - Keep ConMon deliverables from turning into monthly chaos [**Start a free scan**](/app/signup) or [**request a demo**](/request-demo). * * * ## Common Pitfalls (That Quietly Kill Timelines) 1. **Boundary drift:** diagrams and inventories don’t match what’s deployed. 2. **Vague SSP statements:** “we do X” without showing how, where, and evidence. 3. **Tool sprawl without traceability:** evidence exists but nobody can prove it fast. 4. **POA&M wishful thinking:** dates slip, closures lack evidence, reviewers slow down. 5. **ConMon treated as an afterthought:** the first few months post-ATO become constant emergencies. * * * ## Practical “Start Here” Plan (If You’re New) 1. **Freeze the system boundary** and produce diagrams + inventory that reflect reality. 2. **Pick the target baseline** based on customer need and data sensitivity (not ego). 3. **Build operational proof first:** logging, scanning, patching, access reviews. 4. **Draft SSP content with evidence** attached to every major claim. 5. **Engage a 3PAO when stable**, not when “almost ready.” 6. **Design your ConMon cadence** before you submit your package. * * * ## FAQ ### Is FedRAMP mainly security work or documentation work? It’s both—but timelines usually slip because the documentation and evidence traceability isn’t strong enough. Secure systems still fail FedRAMP reviews when the package doesn’t prove the implementation clearly. ### Can I do FedRAMP without changing my engineering workflow? You can—but you’ll suffer. The best teams bake FedRAMP evidence into normal workflows: ticketing, CI/CD, change approvals, and standardized exports. ### What’s the fastest way to reduce FedRAMP pain? Automate evidence collection and keep a clean control → evidence map. That alone can remove weeks of churn. ### FedRAMP Consultant & MSP Playbook: How They Help CSPs Get to ATO (and Stay There) - URL: https://boundera.io/blog/rev5/fedramp-consultant-msp-playbook - Program: FedRAMP Rev 5 - Category: Compliance - Published: 2025-05-09T12:00:00.000Z - Updated: 2026-06-17T20:43:03Z - Reading time: 7 minutes - Main question: How should CSPs use consultants and MSPs during FedRAMP? - TL;DR: External support is most useful when it accelerates readiness, evidence operations, and remediation. It should not replace internal system ownership. - Excerpt: A practical guide to when consultants and MSPs help, where they create leverage, and how to avoid dependency. # FedRAMP Consultant & MSP Playbook: How They Help CSPs Get to ATO (and Stay There) Consultants and managed service providers (MSPs) are most useful when they accelerate the work you would otherwise be slow to start: readiness, evidence operations, and remediation. They should never replace internal ownership of your system, your boundary, or your security program — because the federal government authorizes *you*, not your vendor. The right model is leverage, not dependency: bring in outside help to compress timelines and transfer skills, then own the operating cadence yourself. **Key takeaways** - External support pays off most in three phases: **readiness**, **evidence operations**, and **remediation** — where the gap between "we know what to do" and "it's done" is widest. - You must keep **system ownership** in-house: the authorization boundary, control implementation decisions, the System Security Plan (SSP) as the source of truth, and your continuous monitoring (ConMon) cadence. - A 3PAO that **advises** you on building or preparing a system generally **cannot also be your independent assessor** for that same system — under A2LA's R311 independence policy, the advisor and the assessor must be different parties. - Under the 2026 consolidated rules, authorizations carry a single **"FedRAMP Certified"** label across four **Certification Classes (A, B, C, D)** — there are no numbered "levels" and no "FedRAMP Validated" status. Hire help that uses current terminology. - Automation is increasingly substituting for bodies-for-hire in the most labor-intensive, recurring work — evidence collection, mapping, and freshness — which is where dependency on staff augmentation usually creeps in. ## When do consultants and MSPs actually help? They help most where work is high-effort, time-sensitive, and skill-scarce — and least where it requires durable knowledge of *your* system. Three phases consistently justify outside support. **Readiness.** Before a full assessment, you need a defined authorization boundary, a complete SSP, federal mandates satisfied (FIPS-validated cryptography, FIPS 199 categorization, digital identity requirements), and core capabilities like MFA, encryption, scanning, and incident response actually in place. A good advisor surfaces fatal gaps early — an undefined boundary or non-validated encryption — while they are still cheap to fix. This is exactly the territory our [readiness assessment](/blog/rev5/fedramp-readiness-assessment) guide walks through, and it is where outside experience compresses months of trial and error. **Evidence operations.** Authorization and ConMon both run on evidence: configuration exports, scan results, screenshots with timestamps, policy artifacts, and inventories — all current, traceable, and consistent with the SSP. Standing this up from zero is genuinely hard, and MSPs can help build the pipeline. But this is also the work that quietly turns into permanent staff augmentation if you let it, because evidence is *recurring*. **Remediation.** After an assessment, every finding becomes a Plan of Action and Milestones (POA&M) row with an owner, risk level, and milestone date. Remediation often needs specialized hands — hardening, cryptography, logging architecture — that you may not keep on staff full-time. Bringing in expertise to clear a remediation backlog is a defensible, time-boxed use of consultants. | Phase | Where outside help adds the most leverage | The trap to avoid | | --- | --- | --- | | Readiness | Boundary definition, gap detection, SSP structure, federal-mandate checks | Letting the advisor *own* the boundary instead of teaching you to own it | | Evidence operations | Building the collection pipeline and templates once | Outsourcing evidence forever — it must run after the consultant leaves | | Remediation | Specialist fixes for findings (crypto, hardening, logging) | Treating remediation as the vendor's problem rather than your backlog | > Source: [FedRAMP — Agency Authorization process](https://www.fedramp.gov/agencies/) ## What should you keep in-house? Keep anything that the authorization is fundamentally *about* — the things an Authorizing Official holds you accountable for. The clearest test: if a consultant walked out tomorrow, could you still explain and defend your system? If not, you've outsourced the wrong layer. Four areas should stay in-house even when you lean heavily on outside help: - **The authorization boundary.** This single artifact defines what is in scope. Boundary errors are among the most common and most expensive findings, and only your engineers truly know what processes, stores, and transmits federal data. An advisor can review your diagram; they should not invent your architecture. - **Control implementation decisions.** You can get advice on *how* to implement a control, but the decision and the operating mechanism are yours. The 3PAO will examine, interview, and test the live system — and your own people must be able to describe each control the same way the documents do. - **The SSP as the source of truth.** The most common reason CSPs stall is a gap between the SSP and reality. Keeping the SSP aligned with your architecture as it changes is an ongoing internal discipline, not a one-time deliverable a vendor hands over. - **Your ConMon cadence.** After authorization, monthly scans, POA&M updates, inventory changes, and annual assessment prep never stop. If that rhythm lives entirely with an MSP, you have rented your authorization rather than earned it. | Role | What they do well | What you must keep internal | | --- | --- | --- | | FedRAMP advisory consultant | Strategy, gap analysis, SSP guidance, terminology, path selection | Boundary ownership, final control decisions, accountability to your AO | | MSP / managed security services | Day-to-day operations, scanning, logging, patching execution | The decision of *what* to monitor and *which* risks you accept | | Staff augmentation / contractors | Surge capacity for remediation and documentation backlogs | Long-term knowledge of your system; cross-training your own staff | | 3PAO (assessor) | Independent assessment: SAP, testing, SAR, annual assessment | Nothing to "keep" — by design they are *separate* from you and your advisor | | Compliance automation (e.g., Boundera) | Continuous evidence collection, control-to-evidence mapping, freshness | Judgment on accuracy, the boundary, and risk acceptance | > Source: [FedRAMP — Continuous Monitoring](https://www.fedramp.gov/conmon/) ## Advisor vs. 3PAO: what's the conflict-of-interest rule? A 3PAO that advised on building or preparing your system generally cannot also serve as your independent assessor for that same system. This is the single most important structural rule when you plan outside help, and it trips up CSPs who assume one firm can do everything. The reason is independence. FedRAMP authorizations are trusted across the federal government precisely because the organization testing your controls did not write them. Under the American Association for Laboratory Accreditation (A2LA) **R311** policy — which governs 3PAO independence — a firm that provided advisory or preparation services for a system is barred from performing the independent assessment of that same system for a defined period. The principle is plain: the party that helped author your controls cannot be the one that independently grades them. Practically, this means you should **decide early** whether a given vendor is your *advisor* or your *assessor* — not both. Two clean patterns work: 1. **Advisor + separate 3PAO.** A consultant or MSP helps you reach readiness and build evidence; a structurally independent 3PAO performs the assessment. This is the most common arrangement. 2. **In-house prep + 3PAO.** You handle readiness internally (often with automation) and engage a 3PAO solely for the independent assessment. What does *not* work is hiring one firm to write your SSP and then expecting that same firm to assess it. Confirm a 3PAO's current recognition on the FedRAMP Marketplace, and confirm in writing that it has no advisory entanglement with your system. For the full picture of what assessors look for and how recognition works, see our breakdown of [FedRAMP 3PAO assessors](/blog/rev5/fedramp-3pao-assessors). > Source: [FedRAMP — How a company becomes a recognized 3PAO (independence and quality)](https://help.fedramp.gov/hc/en-us/articles/27704465482139-How-does-a-company-become-a-FedRAMP-recognized-third-party-assessment-organization-3PAO-How-is-the-independence-and-quality-of-a-3PAO-validated) ## How do you avoid dependency on outside help? Avoid dependency by structuring every engagement around knowledge transfer and a defined exit — and by automating the recurring work that would otherwise justify permanent headcount. Dependency is rarely a single decision; it accumulates when no one ever takes the recurring work back in-house. Five practices keep you in control: - **Time-box engagements.** Define start, end, and a concrete deliverable. "Help us pass readiness" has an end; "manage our compliance" does not. - **Require cross-training.** Make knowledge transfer a contractual deliverable. Your staff should be able to run the evidence pipeline and update the SSP after the consultant leaves. - **Own the artifacts and tooling.** The SSP, boundary diagram, POA&M, and evidence repository should live in *your* systems and accounts — not the vendor's. - **Separate advisory from assessment.** Keep R311 in mind from day one so you never have to unwind an entangled relationship near an assessment. - **Automate the recurring, labor-heavy work.** Most "we need more people" pressure in FedRAMP comes from evidence operations — collecting, mapping, and refreshing artifacts every month. This is the work most amenable to automation. This last point is where the economics have shifted. Historically, keeping evidence current across hundreds of controls meant either a large internal team or an ongoing MSP retainer. Automation now does much of that collection and mapping continuously: tools can pull configuration state, tie each artifact to the controls it supports, and flag stale evidence before an assessor does. **Boundera** sits in exactly this layer — it keeps the SSP, evidence, and POA&M aligned automatically, which is why automation increasingly reduces reliance on bodies-for-hire for evidence operations specifically. You still own the judgment; you just stop paying people to copy screenshots. For how this fits the broader market, see our overview of [FedRAMP compliance tooling](/blog/20x/best-fedramp-compliance-tools-2026), and weigh it against the all-in [FedRAMP cost](/blog/20x/fedramp-cost-2026) of staffing the same work manually. ## Does the right help depend on whether you even need FedRAMP? Yes — and this is the first question to settle before hiring anyone. If your federal pipeline does not actually require an authorization, the most expensive consultant you can hire is one who confirms a need that isn't there. Validate demand first: a sponsoring agency or a federal contract requirement should drive the decision, not vendor enthusiasm. Our guide on [whether you need FedRAMP](/blog/20x/do-you-need-fedramp) lays out that gate. Only once the need is real does the consultant-and-MSP question become worth answering — and at that point, the playbook above keeps the spend proportional to the value. ## Frequently asked questions ### Do I need a consultant to get FedRAMP Certified? No. A consultant is optional. Many CSPs reach authorization with a combination of internal expertise and automation, engaging only a 3PAO for the required independent assessment. Consultants add the most value when you lack in-house FedRAMP experience or need to compress your timeline — but the accountability and ownership always remain yours. ### Can the same firm advise me and also be my 3PAO assessor? Generally no. Under A2LA's R311 independence policy, a 3PAO that provided advisory or preparation services for a system cannot perform the independent assessment of that same system for a defined period. Plan your advisory and assessment vendors as separate engagements from the start. ### What's the difference between a FedRAMP consultant and an MSP? A consultant typically advises — strategy, gap analysis, SSP guidance, path selection — and then leaves. An MSP (managed service provider) operates infrastructure and security services on an ongoing basis, such as scanning, logging, and patching. Consultants are usually time-boxed; MSPs are recurring, which makes dependency easier to accumulate if you don't keep ownership and tooling in-house. ### How do I avoid becoming dependent on an MSP? Time-box engagements, require knowledge transfer as a deliverable, keep all artifacts and tooling in your own accounts, and automate the recurring evidence work that otherwise justifies a permanent retainer. The goal is to be able to run your authorization yourself if the vendor disappeared tomorrow. ### Can a consultant write my SSP for me? A consultant can help structure and draft the SSP, but it must describe *your* implemented system accurately, and your own staff must be able to defend every control statement under examine, interview, and test. Treat the SSP as your living source of truth, not a deliverable you receive and file away — gaps between the SSP and reality are the most common reason assessments stall. ### Does automation replace consultants and MSPs? Not entirely, but it replaces a large share of the recurring, labor-intensive evidence work that drives staff-augmentation spend. Automation collects and maps evidence continuously and flags stale artifacts, reducing the need for bodies-for-hire in evidence operations. You still need human judgment for boundary decisions, risk acceptance, and specialist remediation. ### What should I never outsource in a FedRAMP program? Never outsource ownership of your authorization boundary, your control implementation decisions, the SSP as your source of truth, or your continuous monitoring cadence. The federal government authorizes your organization, not your vendor — accountability cannot be delegated. ### Should I hire help before confirming I need FedRAMP? No. Confirm a real federal requirement — typically a sponsoring agency or a contract mandate — before engaging any consultant or MSP. Spending on FedRAMP support before the need is validated is the most common avoidable cost in the entire process. ## Sources - [FedRAMP — Agency Authorization process](https://www.fedramp.gov/agencies/) - [FedRAMP — Continuous Monitoring](https://www.fedramp.gov/conmon/) - [FedRAMP — How a company becomes a recognized 3PAO (A2LA R311 independence)](https://help.fedramp.gov/hc/en-us/articles/27704465482139-How-does-a-company-become-a-FedRAMP-recognized-third-party-assessment-organization-3PAO-How-is-the-independence-and-quality-of-a-3PAO-validated) - [FedRAMP — Certification Classes (2026 Consolidated Rules preview)](https://www.fedramp.gov/preview/2026/agencies/use/classes/) - [NIST SP 800-53 Rev 5 — Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) --- _Last updated: June 2026. Written by the Boundera team. Boundera is an AI copilot for FedRAMP that keeps your SSP, evidence, and POA&M aligned so you can lean on outside help for leverage — not dependency._ ### FedRAMP FAQs & Myths: Straight Answers for CSPs - URL: https://boundera.io/blog/20x/fedramp-faqs-myths - Program: FedRAMP 20x and Rev 5 - Category: FedRAMP Guides - Published: 2025-04-28T12:00:00.000Z - Updated: 2026-06-17T20:43:02Z - Reading time: 7 minutes - Main question: What are the most common myths and FAQs about FedRAMP? - TL;DR: The common traps are underestimating documentation effort, assuming FedRAMP is only for huge companies, and treating authorization like a one-time project. - Excerpt: Direct answers to the questions and misconceptions that slow teams down before they start. # FedRAMP FAQs & Myths: Straight Answers for CSPs The most common FedRAMP traps are underestimating the documentation effort, assuming the program is only for huge companies, and treating authorization as a one-time project instead of an ongoing operating commitment. None of those are true, and clearing them up early is the difference between a clean path to certification and a stalled, expensive one. This page corrects the myths that slow cloud service providers (CSPs) down before they start, then answers the questions teams ask most. It also reflects FedRAMP's 2026 terminology: there is now a single **FedRAMP Certified** label, and assessment baselines map to **Certification Classes A, B, C, and D** rather than numbered "levels." **Key takeaways** - FedRAMP is now a single certification. The label is **FedRAMP Certified**; there is no "FedRAMP Validated," no separate brand for 20x vs. Rev 5, and no numbered levels. - Baselines are described as **Certification Classes**: Class A (pilot), Class B (current LI-SaaS and Low), Class C (current Moderate), Class D (current High). - The biggest cost driver is usually evidence and documentation, not the technology. - A FedRAMP Certification is reusable risk material; an **agency ATO** is a separate decision an agency makes using that material. - Authorization is the start of a continuous monitoring commitment, not the finish line. ## Myth: FedRAMP is only for big companies? Reality: FedRAMP is for any cloud service a federal agency wants to use, and the program has been actively reshaped to lower the barrier for smaller and cloud-native providers. The FedRAMP 20x track is designed specifically for well-scoped, cloud-native services without significant legacy technical debt, which is precisely the profile of many startups and mid-market SaaS companies. What actually determines difficulty is scope and architecture, not headcount or revenue. A tightly scoped single-tenant SaaS with a clean cloud boundary is often easier to certify than a sprawling enterprise system with multiple data centers. If you sell software the government wants to buy, you are a candidate. See [FedRAMP for startups](/blog/20x/fedramp-for-startups) for how smaller teams approach this, and [do you actually need FedRAMP](/blog/20x/do-you-need-fedramp) to confirm it applies to you before investing. ## Myth: a SOC 2 report covers FedRAMP? Reality: SOC 2 and FedRAMP are different frameworks with different authorities, and one does not substitute for the other. SOC 2 is a private-sector attestation against the AICPA Trust Services Criteria. FedRAMP is a U.S. government certification built on NIST SP 800-53 controls, assessed by an accredited third-party assessment organization (3PAO), and governed by the FedRAMP Authorization Act and OMB policy. A mature SOC 2 program absolutely helps. Many of the same controls (access management, change control, logging, incident response) overlap, and your existing evidence can be reused. But FedRAMP requires far more controls, a defined system boundary, FedRAMP-specific documentation, and continuous monitoring on a government cadence. Treat SOC 2 as a head start, not a shortcut. ## Myth: authorization is a one-time project? Reality: Achieving certification is the beginning of an ongoing obligation, not a one-and-done milestone. Once certified, a CSP must run **continuous monitoring (ConMon)**: monthly vulnerability scanning, ongoing POA&M management, configuration and change management, annual assessments, and timely incident reporting. Let ConMon lapse and your standing is at risk. This is why the operating cost matters as much as the initial assessment cost. Budgeting only for the first authorization and not for the recurring program is one of the most common planning mistakes we see. Factor the full lifecycle into your plan from day one — [what FedRAMP costs](/blog/20x/fedramp-cost-2026) breaks down both the upfront and recurring spend. ## Myth: FedRAMP and an agency ATO are the same? Reality: They are two distinct decisions. A **FedRAMP Certification** produces a reusable package of security materials. An **agency Authorization to Operate (ATO)** is a separate determination an agency's authorizing official makes when they decide to actually run your service inside one of their federal information systems. FedRAMP itself is explicit about this: under the FedRAMP Authorization Act, a certification is "a certification that a cloud computing product or service has completed a FedRAMP authorization process," and the resulting package is the essential information an agency uses to decide whether to authorize operation. FedRAMP does not accept risk on an agency's behalf — agencies do that themselves using your package, and they may do so at the security category they deem appropriate. In short: FedRAMP certifies the package; the agency issues the ATO. ## Myth: I still need to ask for "FedRAMP Validated" or pick a numbered level? Reality: That language is outdated as of 2026. Per FedRAMP's [NTC-0004 notice](https://www.fedramp.gov/notices/0004/), the single official label for all FedRAMP authorizations is **FedRAMP Certification** / **FedRAMP Certified**. There is deliberately no separate "FedRAMP Validated" designation, and 20x and Rev 5 do not get different brand labels — FedRAMP differentiates the paths with marketplace filters instead. FedRAMP also retired numbered "levels" for baseline labels to avoid confusion with the DoD Impact Level (IL) system. Baselines are now described as Certification Classes. Here is how the old and new language line up: | Outdated / incorrect term | Correct 2026 term | | --- | --- | | "FedRAMP Validated" | FedRAMP Certified (single label) | | "FedRAMP Authorized" as the brand | FedRAMP Certification / FedRAMP Certified | | Separate 20x vs. Rev 5 labels | One label; marketplace filters distinguish paths | | Numbered impact "levels" | Certification Classes A / B / C / D | | LI-SaaS / Low | Class B | | Moderate | Class C | | High | Class D | | (new pilot baseline) | Class A | > Source: [FedRAMP NTC-0004, Initial Outcome from RFC-0020 FedRAMP Authorization Designations](https://www.fedramp.gov/notices/0004/) ## What do the Certification Classes actually mean? Reality: A Certification Class describes the depth and complexity of the assessment baseline — how much information a CSP must provide — not a verdict on the overall security of the service. FedRAMP stresses that the baseline "defines the scope of the assessment and certification by FedRAMP, not the total quality or security of the cloud service." | Class | Maps to | Typical fit | | --- | --- | --- | | Class A | New pilot baseline | Entry-level / tightly scoped, lower-risk environments | | Class B | Current LI-SaaS and Low | Public or non-sensitive government data; limited breach impact | | Class C | Current Moderate | The most common tier; CUI and non-public federal data | | Class D | Current High | Highest-sensitivity systems | > Source: [FedRAMP NTC-0004](https://www.fedramp.gov/notices/0004/) and [FedRAMP Consolidated Rules for 2026 public preview](https://www.fedramp.gov/preview/2026/certification/) FedRAMP has stated the baseline requirements themselves change only minimally in the 2026 Consolidated Rules; the labels change, with a transition period that links old and new names. The Consolidated Rules for 2026 (CR26) are slated to publish by the end of June 2026 and remain valid through December 31, 2028. ## Frequently asked questions ### Is FedRAMP mandatory? For cloud services used by U.S. federal agencies, yes — FedRAMP authorization is required under the FedRAMP Authorization Act and OMB policy. It is not required to sell to the private sector or to state and local governments that do not mandate it. Before you invest, confirm it applies to your buyers; [do you actually need FedRAMP](/blog/20x/do-you-need-fedramp) walks through that decision. ### What is the difference between FedRAMP 20x and Rev 5? They are two paths to the same FedRAMP Certified outcome, not two different certifications. FedRAMP 20x is the newer, automation-forward track aimed at well-scoped, cloud-native services. Rev 5 is the established path better suited to larger or more complex providers, including those pursuing Class D (High). Both align to the same Certification Classes, and FedRAMP uses marketplace filters rather than separate labels to distinguish them. ### How long does FedRAMP authorization take? It varies widely by path, scope, and readiness. The 20x track is designed to be substantially faster for clean, cloud-native scopes, while a complex Rev 5 effort can run a year or more end to end. The single biggest schedule risk is documentation and evidence readiness, not the technology. ### What does FedRAMP cost? Costs span an upfront assessment and an ongoing continuous-monitoring program, and they scale with scope and Certification Class. Plan for both, not just the initial authorization — the recurring ConMon spend is where teams most often under-budget. See [what FedRAMP costs](/blog/20x/fedramp-cost-2026) for a current breakdown. ### Do I need an agency sponsor? It depends on the path. FedRAMP 20x is designed to enable certain authorizations without an agency sponsor, which removes a long-standing bottleneck for smaller providers. Traditional agency-sponsored authorization still exists and is common for higher-complexity systems. ### What is a 3PAO? A 3PAO is an accredited Third-Party Assessment Organization that independently tests your security controls and validates your evidence. FedRAMP assessments must be performed by a 3PAO; you cannot self-attest your way to certification. ### What is continuous monitoring (ConMon)? ConMon is the ongoing program you run after certification: monthly vulnerability scanning, POA&M tracking and remediation, configuration and change management, incident reporting, and periodic reassessment. It is a permanent operating cost, and neglecting it puts your certification at risk. ### Does a SOC 2 or ISO 27001 report make me FedRAMP compliant? No. Those frameworks overlap with FedRAMP and give you reusable evidence and a stronger starting posture, but neither satisfies FedRAMP's NIST SP 800-53 control set, boundary definition, 3PAO assessment, or continuous monitoring requirements. ### Is "FedRAMP Validated" a real designation? No. As of 2026, FedRAMP uses a single label — FedRAMP Certified — for all authorizations. There is no "FedRAMP Validated," and there are no separate labels for 20x and Rev 5. ### Where should I start? Start by confirming the requirement and defining your system boundary tightly, since scope drives nearly everything that follows. Our [complete FedRAMP authorization guide](/blog/rev5/complete-fedramp-authorization-guide-2025) lays out the full path from readiness through continuous monitoring. ## Sources - [FedRAMP NTC-0004 — Initial Outcome from RFC-0020 FedRAMP Authorization Designations (fedramp.gov)](https://www.fedramp.gov/notices/0004/) - [FedRAMP Consolidated Rules for 2026 — Certification (public preview, fedramp.gov)](https://www.fedramp.gov/preview/2026/certification/) - [FedRAMP Certification Classes (public preview, fedramp.gov)](https://www.fedramp.gov/preview/2026/agencies/use/classes/) - [FedRAMP Authorization Act — definitions (fedramp.gov)](https://www.fedramp.gov/docs/authority/law/definitions/) - [NIST SP 800-53 Security and Privacy Controls (NIST)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) --- _Last updated: June 2026. Written by the Boundera team._ ### Automation, OSCAL, and AI for FedRAMP: A Practical Guide for CSPs - URL: https://boundera.io/blog/20x/automation-oscal-ai-for-fedramp - Program: FedRAMP 20x - Category: Automation - Published: 2025-04-14T12:00:00.000Z - Updated: 2026-06-17T20:43:01Z - Reading time: 9 minutes - Main question: How can automation, OSCAL, and AI speed up FedRAMP work? - TL;DR: Automation helps most with evidence collection, normalization, traceability, and documentation scaffolding. Human review still matters for scoping and risk acceptance. - Excerpt: Where automation actually helps in FedRAMP and where teams still need human review. ## Why “Automation + OSCAL” is the real FedRAMP unlock Most FedRAMP pain comes from the same root problem: your compliance “system” is a pile of documents that drift the moment engineers ship changes. You can do heroic documentation sprints… or you can make the package behave more like software. That’s what OSCAL enables. [OSCAL (Open Security Controls Assessment Language)](/blog/20x/oscal-for-fedramp-guide) is a NIST-led set of formats (JSON/XML/YAML) that represents controls, system implementations, assessment work, and remediation plans as structured data. When your SSP, SAP, SAR, and POA&M are structured, you can validate them, diff them, auto-generate sections, and keep them continuously updated instead of rewriting them from scratch. ## What OSCAL changes for a CSP pursuing FedRAMP Think of FedRAMP as four ongoing streams of work: - **Controls:** what you must implement (baseline requirements) - **Implementation:** how your system actually meets those requirements - **Assessment:** what a 3PAO tested and what they found - **Remediation:** what you’re fixing (POA&M) and how fast you close issues In a traditional approach, each stream becomes a separate document (or spreadsheet) with tons of manual copy/paste. In an OSCAL-first approach, each stream becomes a model, and your “package” becomes a set of files your tooling can reason about. ## Where OSCAL fits in the FedRAMP package At a practical level, OSCAL lets you represent the same package reviewers already expect — just in a structured format. Most teams care about these artifacts: - **SSP:** your system description + control implementation narratives - **SAP:** what will be tested, how, by whom, and when - **SAR:** assessment results and findings - **POA&M:** your plan to remediate findings and ongoing issues Even if you still export a human-readable SSP for stakeholders, the win is using structured data as the source of truth. That makes your package easier to maintain and harder to accidentally break. ## What you can automate (realistically) without risking reviewer backlash ### 1) Evidence collection that doesn’t depend on screenshots Stop treating evidence as “random PDFs in a folder.” Treat evidence as a pipeline: - Pull logs/configs from cloud and identity systems on a schedule - Normalize evidence into consistent objects (who/what/when/where) - Attach evidence to the exact control statements it supports - Keep a change history so you can prove continuity ### 2) Control-to-evidence mapping (with confidence + review) Mapping is where teams bleed time. Good automation does two things: - **Suggests mappings:** “This artifact supports AC-2(1), AU-2, AU-12…” - **Shows why:** what signal triggered the mapping, and what evidence is missing The “why” matters. Reviewers don’t reward vibes. They reward traceability. ### 3) Drift detection tied to your FedRAMP boundary In the real world, your system changes weekly. Drift detection is the difference between “we’re compliant” and “we were compliant two quarters ago.” Automation can: - Detect new resources/services added inside the boundary - Flag configuration drift from your baselines - Trigger evidence refreshes and update affected control narratives - Generate “what changed” summaries for [ConMon](/blog/rev5/fedramp-conmon-checklist) and annual assessment prep ### 4) POA&M lifecycle that doesn’t rot POA&Ms fail when they become stale and political. A strong automated workflow: - Ingests findings from scanners, assessments, and tickets - Deduplicates and groups related issues - Tracks aging, exceptions, false positives, and risk acceptance cleanly - Links each item to evidence of remediation (before/after) ## Where AI helps (and where it hurts) in FedRAMP work AI is useful in FedRAMP when it behaves like a disciplined assistant — not a creative writer. Here’s the safe use pattern: - **Drafting:** generate first-pass control narratives in a strict template - **Gap spotting:** highlight missing control elements (“you described MFA but didn’t address re-auth frequency”) - **Normalization:** turn messy evidence into consistent summaries with links back to sources - **Reviewer simulation:** run a “FedRAMP reviewer checklist” pass before you submit Where AI hurts: when it invents implementation details, overstates coverage, or produces vague language. If a statement can’t be backed by evidence inside your boundary, it’s a liability. ## A practical implementation plan (30 / 60 / 90 days) ### Days 0–30: Make your inventory + evidence pipeline real - Define your FedRAMP boundary in a way engineers can’t misinterpret - Start collecting inventory, IAM, logging, and vuln data on a schedule - Decide your evidence format (IDs, timestamps, source system, retention) ### Days 31–60: Establish control mappings and narrative templates - Pick a small set of control families first (AC, AU, CM, IR are great starters) - Create strict narrative templates: “what / how / where / who / frequency / evidence” - Introduce reviewer-style QA checks (specificity, evidence linkage, boundary clarity) ### Days 61–90: Start generating OSCAL artifacts and validating them - [Convert your structured content into OSCAL](/blog/20x/ssp-to-oscal-guide) SSP/SAP/SAR/POA&M files - Validate: schema checks, completeness checks, required fields, IDs, references - Export human-friendly versions for stakeholders, but keep OSCAL as the source of truth ## How Boundera fits into this workflow Boundera is built for the exact problems that make FedRAMP slow: - **Automated evidence collection:** connect cloud + identity + dev tools and keep evidence current - **Control mapping:** suggest mappings and show what’s missing - **Gap analysis:** identify weak or incomplete narratives early - **Package output:** generate clean OSCAL JSON/XML/YAML artifacts you can iterate on as your system evolves The goal isn’t “AI replaces compliance.” The goal is a compliance engine that keeps up with your engineers. ## Common mistakes to avoid 1. **Trying to “OSCAL everything” on day one:** start with the controls that drive the most evidence churn. 2. **Letting narratives get vague:** reviewers want specifics (services, settings, retention periods, roles, frequency). 3. **Evidence without context:** raw exports aren’t enough; include what the artifact proves and where it applies. 4. **Not tying drift to ConMon:** drift must trigger updates, not just alerts. ## Key takeaways - OSCAL turns FedRAMP from “documents” into “data,” which unlocks real automation. - The biggest win is after ATO: continuous monitoring becomes cheaper, faster, and less stressful. - AI is most valuable for drafts and gap detection — but only when grounded in evidence and strict templates. ## References (official starting points) - [FedRAMP Automation (OSCAL templates + tooling)](https://github.com/GSA/fedramp-automation) - [FedRAMP OSCAL Documentation](https://automate.fedramp.gov/documentation/) - [NIST OSCAL documentation](https://pages.nist.gov/OSCAL/) - [FedRAMP Digital Authorization Package Pilot](https://www.fedramp.gov/2024-08-28-digital-authorization-pilot/) ### FedRAMP Continuous Monitoring After ATO: Monthly, Quarterly, and Annual Checklist - URL: https://boundera.io/blog/rev5/fedramp-continuous-monitoring-after-ato - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2025-04-02T12:00:00.000Z - Updated: 2026-06-17T20:43:00Z - Reading time: 8 minutes - Main question: What does continuous monitoring actually require after ATO? - TL;DR: Authorization is the midpoint, not the end. The work shifts to recurring scans, POA&M hygiene, evidence freshness, and change reporting. - Excerpt: A practical operating checklist for continuous monitoring after you achieve authorization. # FedRAMP Continuous Monitoring After ATO: Monthly, Quarterly, and Annual Checklist Authorization is the midpoint, not the finish line. The day you receive your Authority to Operate (ATO), your job changes from *building and proving* a one-time package to *operating and sustaining* it forever: recurring vulnerability scans, disciplined Plan of Action and Milestones (POA&M) hygiene, evidence that stays fresh, and change reporting that reaches your agency Authorizing Official (AO) before — not after — you act. Continuous monitoring (ConMon) is the program that keeps your authorization alive, and it runs on a fixed rhythm of monthly, quarterly, annual, and as-needed obligations. This post is about what changes after ATO and how to build the operating rhythm; for the line-item task list, see our companion [monthly and annual ConMon checklist](/blog/rev5/fedramp-conmon-checklist). **Key takeaways** - ConMon **begins the moment you are authorized and never stops** while you hold an authorization — it is an operating function, not a project with an end date. - The work splits across four cadences: **monthly** (scans, POA&M, inventory), **quarterly** (POA&M trend review, recurring scan verification), **annual** (independent assessment, plan testing, SSP refresh), and **as-needed** (significant changes, deviation requests, incidents). - Remediation runs on a clock: **Critical 30 days, High 90 days, Moderate 180 days, Low 365 days** from detection. - An ATO can be **suspended or revoked** for sustained ConMon failure — missed monthly submissions, an unmaintained POA&M, undisclosed significant changes, or an unfavorable annual assessment. - The 2026 terminology (NTC-0004) uses a single **FedRAMP Certified** label and four **Certification Classes (A, B, C, D)**; the ConMon cadence is the same across classes. ## What changes after you get your ATO? The fundamental shift is from a *snapshot* to a *stream*. Your initial package proved your security posture on one assessment date; ConMon proves it is still true every month. Three things change in practice. First, **the burden of proof becomes recurring.** Before ATO, you assembled evidence once for a 3PAO. After ATO, you generate fresh evidence on a schedule and submit it to your secure repository for ongoing AO review. Stale evidence is now a finding in its own right. Second, **change is governed, not free.** Pre-ATO you could re-architect at will. Post-ATO, any change that could materially affect your security posture requires a security impact analysis up front and, for significant changes, AO approval before you act. The authorization boundary is now a contract. Third, **ownership moves from a project team to an operating function.** The readiness sprint that got you authorized disbands; a standing ConMon function — typically led by an ISSO with security, operations, and remediation owners — takes over and runs indefinitely. Teams that treat ConMon as "the project is done" are the ones that drift. The recurring nature is also the part most CSPs underestimate financially, which we break down in the [ongoing cost of FedRAMP](/blog/20x/fedramp-hidden-costs). > Source: [FedRAMP Continuous Monitoring Overview — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/overview/) ## What are the monthly, quarterly, and annual obligations? ConMon obligations fall on four cadences. The table below maps each cadence to its core obligation and the typical owner, so the rhythm is clear at a glance. Use it to staff the function; use the [monthly and annual ConMon checklist](/blog/rev5/fedramp-conmon-checklist) for the granular task list and submission mechanics. | Cadence | Core obligation | Typical owner | | --- | --- | --- | | Monthly | Vulnerability scans (OS, web app, database); update POA&M; update inventory; submit ConMon report; hold AO review | CSP security/ops + ISSO | | Monthly | Track remediation against SLA clocks (Crit 30 / High 90 / Mod 180 / Low 365 days) | Remediation owners | | Quarterly | Review POA&M trends (aging items, milestone slippage); confirm scan coverage still matches the boundary; reconcile inventory drift | ISSO / compliance lead | | Annual | Independent assessment of a control subset; updated SAR | 3PAO / independent assessor | | Annual | Test Incident Response Plan and Contingency Plan; refresh SSP and appendices | CSP + ISSO | | As-needed | Significant change request + security impact analysis; AO approval | CSP → AO approves | | As-needed | Deviation requests (false positive, risk adjustment, operational requirement) | CSP → AO approves | | As-needed | Incident reporting per agreed timelines | CSP → AO / CISA | | Every 3 years | Broader reassessment / re-authorization activities | CSP + assessor | A note on quarterly work: FedRAMP's formal reporting cadences are monthly, annual, every three years, and as-needed. Quarterly is not a separate FedRAMP submission deadline — it is the operating discipline mature CSPs add on top, because a quarter is the right interval to catch POA&M aging, scan-coverage gaps, and inventory drift *before* they surface in the annual assessment. Treat quarterly as your internal early-warning review, not a government due date. > Source: [FedRAMP Continuous Monitoring Strategy Guide (PDF) — fedramp.gov](https://www.fedramp.gov/assets/resources/documents/CSP_Continuous_Monitoring_Strategy_Guide.pdf) ## What does the annual assessment require? Once a year, an independent assessor performs a fresh evaluation of a selected subset of your controls and produces an updated Security Assessment Report (SAR). This is a real assessment, not a documentation refresh — the assessor examines evidence, interviews staff, and tests the live system, and every new finding flows into your POA&M under the same SLA clock as any monthly finding. Alongside the assessment, you keep your authorization package honest. You update the System Security Plan and its appendices to reflect the system as it actually runs, and you **test your Incident Response Plan and Contingency Plan** so those controls are demonstrably exercised rather than merely written. The annual assessment is effectively where your year of monthly hygiene gets graded: if your scans, POA&M, and inventory have been accurate all year, the assessor confirms what the AO already knows; if the cadence slipped, this is where that debt comes due. For what assessors actually look for, see our guide to the [3PAO annual assessment](/blog/rev5/fedramp-3pao-assessors). ## What causes an ATO to be revoked? An ATO is a standing decision by an AO that your residual risk is acceptable — and it can be withdrawn when that judgment no longer holds. Revocation is rarely a single dramatic event; it is usually the end state of accumulated ConMon failure. The common triggers: - **Missed or incomplete monthly submissions.** When scans, POA&M, and inventory stop arriving on schedule, the AO loses visibility into your current posture and can no longer justify the risk acceptance. - **An unmaintained POA&M.** Findings that blow past their SLA dates with no progress, or milestones that keep slipping, signal a system whose risk is no longer being managed. - **Undisclosed significant changes.** Altering the boundary, adding an external connection, or swapping a core component without a security impact analysis and AO approval breaks the authorization contract. - **An unfavorable annual assessment.** Material new findings, or evidence that the system no longer matches its documented controls, can prompt the AO to reconsider. - **An unreported or mishandled incident.** Security incidents that are not reported per agreed timelines erode the trust the authorization depends on. The practical defense is the same in every case: keep the operating rhythm clean so the AO never has reason to lose confidence. An ATO is preserved by months of unremarkable, on-time, accurate submissions — not by heroics when something is already on fire. > Source: [FedRAMP Significant Changes — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/significant-changes/) ## How do you build a ConMon operating rhythm that survives? The hard part of ConMon is not any single deliverable — it is producing all of them accurately, every month, forever, while still shipping product. The failure mode is predictable: scans run late, the POA&M drifts out of sync with the latest scan results, the inventory stops matching reality, and the team scrambles in the final days before the upload. That scramble is where missed SLAs and authorization risk are born. The fix is to treat ConMon as a continuous pipeline rather than a recurring project. At Boundera, our AI copilot keeps the three monthly artifacts in lockstep: scan results feed POA&M entries with the correct control mapping and SLA clock, the inventory reconciles against what is actually deployed inside the boundary, and the monthly package assembles from a system of record that is always current. The copilot does not replace your ISSO's judgment on deviations or significant changes; it removes the manual reconciliation that turns a routine upload into a fire drill, so human review happens on clean, complete data and the AO sees a steady, trustworthy stream. ## Frequently asked questions ### What does continuous monitoring actually require after ATO? After ATO, ConMon requires **monthly** vulnerability scans (OS, web app, database), an updated POA&M, an updated inventory, and a ConMon report; an **annual** independent assessment plus plan testing and SSP refresh; broader reassessment **every three years**; and **as-needed** significant change requests, deviation requests, and incident reports. The unifying requirement is keeping your security posture visible and current so the AO's risk acceptance stays valid. ### Is FedRAMP continuous monitoring really quarterly? Not as a federal deadline. FedRAMP's formal reporting cadences are **monthly, annual, every three years, and as-needed**. A quarterly review is an internal operating discipline many mature CSPs add to catch POA&M aging, scan-coverage gaps, and inventory drift before the annual assessment — valuable, but not a government submission date. ### What are the monthly ConMon deliverables after authorization? Vulnerability scans of your operating systems, web applications, and databases; an updated POA&M; an updated inventory; and a monthly ConMon report, all submitted to your secure repository for AO review. Raw scan files are provided when your agency agreements require them. ### Can your FedRAMP ATO be revoked? Yes. An AO can suspend or revoke an ATO for sustained ConMon failure — missed monthly submissions, an unmaintained POA&M, undisclosed significant changes, an unfavorable annual assessment, or unreported incidents. Revocation is usually the end state of accumulated drift, not a one-time event. ### What are the FedRAMP POA&M remediation timelines? Findings must be remediated within standard timelines from detection: **Critical in 30 days, High in 90 days, Moderate in 180 days, and Low in 365 days**. Missed milestones must be tracked in the POA&M and can become findings themselves, so set realistic completion dates. ### Does the 2026 FedRAMP terminology change ConMon? The shift to a single **FedRAMP Certified** label and four **Certification Classes (A, B, C, D)** under NTC-0004 changes how baselines are named, not the underlying monthly-scan, POA&M, and inventory rhythm. The expectation — keep risk posture visible and current — is the same across classes. ### How is ConMon different from getting authorized in the first place? Authorization proves your posture once, on an assessment date; ConMon proves it is still true every month thereafter. The burden of proof becomes recurring, change becomes governed by security impact analysis and AO approval, and ownership moves from a temporary readiness team to a standing operating function. ## Sources - [FedRAMP Continuous Monitoring Overview — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/overview/) - [FedRAMP Continuous Monitoring Strategy Guide (PDF) — fedramp.gov](https://www.fedramp.gov/assets/resources/documents/CSP_Continuous_Monitoring_Strategy_Guide.pdf) - [FedRAMP Annual Assessment — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/annual-assessment/) - [FedRAMP Significant Changes — fedramp.gov](https://www.fedramp.gov/docs/rev5/playbook/csp/continuous-monitoring/significant-changes/) - [NTC-0004: FedRAMP Certification labels and Classes — fedramp.gov](https://www.fedramp.gov/notices/0004/) - [NIST SP 800-137, Information Security Continuous Monitoring — nist.gov](https://csrc.nist.gov/pubs/sp/800/137/final) --- _Last updated: June 2026. Written by the Boundera team._ ### FedRAMP vs SOC 2 vs CMMC vs StateRAMP: Which One Do You Actually Need? - URL: https://boundera.io/blog/20x/fedramp-vs-soc2-vs-cmmc-vs-stateramp - Program: FedRAMP 20x and Rev 5 - Category: Compliance - Published: 2025-03-19T12:00:00.000Z - Updated: 2026-06-17T20:42:59Z - Reading time: 10 minutes - Main question: Which compliance framework does my company actually need first? - TL;DR: Choose based on who buys from you. Federal civilian buyers push you toward FedRAMP, DoD toward CMMC, and commercial enterprise toward SOC 2. - Excerpt: A buyer-focused comparison of the major compliance frameworks cloud companies get pulled into. **If you’re building a cloud product, compliance can feel like a maze.** People throw around FedRAMP, SOC 2, CMMC, and StateRAMP like they’re interchangeable. They’re not. This post is the practical version: what each framework actually proves, who asks for it, and the cleanest order to pursue them without doing everything twice. * * * ## Quick answer: pick based on who pays you - **Federal civilian agencies (or federal prime opportunities):** prioritize **FedRAMP**. - **Enterprise/commercial buyers:** prioritize **SOC 2** (fastest “security credibility” milestone). - **DoD supply chain (FCI/CUI in contracts):** prioritize **CMMC** based on contract requirements. - **State/local government:** you may need **StateRAMP** (or an equivalent state-focused authorization path). **Most SaaS companies that want FedRAMP later:** do SOC 2 first, then FedRAMP once there’s real federal demand. * * * ## Table of contents 1. [One-table comparison](#comparison-table) 2. [FedRAMP: when it’s mandatory](#fedramp) 3. [SOC 2: the fastest trust milestone](#soc2) 4. [CMMC: contract-driven for DoD supply chain](#cmmc) 5. [StateRAMP: state/local authorization](#stateramp) 6. [What you can reuse across all of them](#reuse) 7. [Recommended order (common paths)](#recommended-order) 8. [Where Boundera fits](#where-boundera-fits) * * * ## FedRAMP vs SOC 2 vs CMMC vs StateRAMP (one-table comparison) Framework Who it’s for What it proves Underlying basis Output Typical pain **FedRAMP** U.S. federal cloud procurement Security authorization package accepted for federal use NIST 800-53 (baselines) SSP + SAP/SAR + POA&M + ongoing ConMon Documentation volume + evidence quality + assessor rigor **SOC 2** Commercial/enterprise trust Independent attestation of controls over time (Type II) AICPA Trust Services Criteria SOC 2 report (Type I or Type II) Operational maturity + consistent evidence collection **CMMC** DoD contractors & supply chain Cyber maturity aligned to contract expectations NIST 800-171 (and program rules) CMMC level assessment/certification (contract-driven) Scoping CUI/FCI, proving practices are institutionalized **StateRAMP** State & local government procurement Standardized authorization for SLED buyers Often NIST 800-53-based baselines Status/listing + security package + monitoring Different state expectations + program-specific packaging _Important:_ your exact “must-have” depends on your buyers and contract language. Don’t over-build compliance that nobody is asking you for yet. * * * ## FedRAMP: when it’s mandatory **FedRAMP is the gate** when your product is sold as a cloud service to U.S. federal agencies (or you want to be “procurement-ready” for federal pipelines). ### What FedRAMP actually requires - **Control implementation:** you implement the baseline controls (e.g., Low/Moderate/High) and document exactly how. - **Assessment:** a FedRAMP-accredited assessor (3PAO) tests the implementation. - **Package:** you submit a package (SSP, SAR, POA&M, policies, evidence). - **Continuous monitoring:** you maintain compliance after authorization (not “one and done”). ### When FedRAMP is the wrong first step - You have **no real federal pipeline** and are still searching for product-market fit. - Your product can win commercial deals faster with SOC 2, and you need revenue first. - You can’t commit to continuous monitoring and documentation maintenance. If your goal is “sell to federal,” FedRAMP is unavoidable. If your goal is “be trusted by enterprises now,” SOC 2 often gets you there quicker. For a deeper side-by-side, see [FedRAMP vs SOC 2](/blog/20x/fedramp-vs-soc2). * * * ## SOC 2: the fastest trust milestone (for most SaaS) SOC 2 is the most common “prove you’re serious about security” milestone for enterprise buyers. ### What SOC 2 does well - Gets you through **security reviews** with commercial customers. - Forces **repeatable processes**: access reviews, change management, incident response, vendor management, etc. - Creates a clean evidence habit you can later reuse for FedRAMP-style work. ### Type I vs Type II in plain English - **Type I:** “Designed properly” at a point in time. - **Type II:** “Designed + operating effectively” over a period (what most buyers actually want). **If you’re early-stage:** SOC 2 is usually the best ROI because it unlocks revenue faster, and that same operational discipline helps when you pursue FedRAMP later. * * * ## CMMC: contract-driven for the DoD supply chain CMMC matters when you’re doing business in the DoD ecosystem—especially when contracts include requirements for handling **FCI** (Federal Contract Information) or **CUI** (Controlled Unclassified Information). ### Who should care about CMMC - Defense contractors, subcontractors, and vendors touching CUI/FCI. - SaaS providers that become part of a contractor’s workflow where CUI is processed. ### A common mistake People confuse **FedRAMP** (cloud authorization for federal agencies) with **CMMC** (cyber maturity requirements tied to DoD contracting). You might need one, the other, or both—depending on who your customer is and what your system touches. See [FedRAMP vs CMMC](/blog/rev5/fedramp-vs-cmmc) for the full breakdown. **Rule of thumb:** follow contract requirements. If you aren’t yet in that contract chain, don’t burn months optimizing for hypothetical requirements. * * * ## StateRAMP: state/local authorization [StateRAMP](/blog/rev5/fedramp-vs-stateramp-govramp) is used in state and local government procurement to standardize cloud security reviews. In practice, it can look similar to FedRAMP: baseline controls, required documentation, third-party assessment, and ongoing monitoring—just tailored for SLED buyers. ### When StateRAMP is the driver - You’re selling into **state, county, city, or education** buyers who explicitly ask for StateRAMP (or equivalent) status. - You need to be on an approved list to shorten procurement timelines. **Good news:** if you’ve built a strong NIST-style control program (FedRAMP-ish), you typically have a lot to reuse for StateRAMP-style packaging. * * * ## What you can reuse across all four frameworks This is where companies save months: reuse the same “security operating system,” then map it differently. ### High-reuse evidence (usually 80% of the work) - **Identity & access:** MFA enforcement, SSO, access reviews, privileged access controls - **Logging & monitoring:** centralized logs, alerting, retention, time sync - **Vulnerability management:** scanning cadence, patch SLAs, remediation tracking - **Incident response:** IR plan, tabletop exercises, ticket evidence - **Change management:** PR approvals, CI checks, release logs - **Vendor management:** third-party risk reviews, DPAs, security questionnaires - **Backup/DR:** tested restores, RPO/RTO targets, runbooks - **Policies & procedures:** same core docs, different mappings **The real difference** is how strict the assessor is, the required format, and how “package-heavy” the program is (FedRAMP being the heavyweight champion). * * * ## Recommended order (common paths) ### Path A: SaaS → enterprise now, federal later 1. **SOC 2 (Type II)** to unlock enterprise deals 2. **FedRAMP readiness + packaging** once you have a real federal pipeline ### Path B: Federal-first (you already have federal pull) 1. **FedRAMP readiness** (close gaps fast) 2. **FedRAMP package build** (SSP, evidence, assessment readiness) 3. **ConMon automation** so you don’t drown after ATO ### Path C: DoD supply chain (CUI/FCI in contracts) 1. **CMMC-aligned practices** (scoped to where CUI/FCI lives) 2. **Then add FedRAMP** if you’re selling cloud services directly to federal agencies ### Path D: SLED-first (state/local buyers) 1. **StateRAMP** if it’s required in your pipeline 2. **SOC 2** as a broader commercial trust asset (optional but helpful) * * * ## Where Boundera fits Most teams don’t fail compliance because they’re insecure. They fail because they can’t produce a clean, consistent package fast enough. **Boundera** is built for the “package” problem: - Connect your systems (AWS, GitHub, Okta, etc.) and **pull evidence** consistently - **Map evidence to controls** so you aren’t doing spreadsheet archaeology - Generate a **Gap Analysis** you can actually execute - Draft FedRAMP-style documentation faster (then you review and finalize) If you’re exploring FedRAMP, start with the pillar guide next: - [Complete FedRAMP Authorization Guide](/blog/complete-fedramp-authorization-guide-2025) * * * ## Bottom line **Don’t chase compliance trophies.** Chase the one your buyers require, build a reusable control program underneath it, and package it efficiently. ### FedRAMP 20x + Authorization Act Updates: What Changed and What CSPs Should Do Next - URL: https://boundera.io/blog/20x/fedramp-20x-authorization-act-updates - Program: FedRAMP 20x - Category: FedRAMP Guides - Published: 2025-03-03T12:00:00.000Z - Updated: 2026-06-17T20:42:58Z - Reading time: 9 minutes - Main question: What changed with FedRAMP 20x and what should CSPs do next? - TL;DR: FedRAMP is moving toward faster, more automated evidence-driven workflows. CSPs should tighten boundary clarity, machine-readable evidence, and repeatable control narratives. - Excerpt: What the latest FedRAMP modernization signals mean for CSP roadmaps, automation priorities, and authorization strategy. # FedRAMP 20x + Authorization Act Updates: What Changed and What CSPs Should Do Next FedRAMP has shifted from a slow, document-heavy compliance program to a faster, automation-driven model anchored in statute. As of June 2026, the **FedRAMP Authorization Act** (Public Law 117-263) provides the legal foundation, **FedRAMP 20x** is in **Phase 3 (wide adoption)**, and the **Consolidated Rules for 2026 (CR26)** are due by the end of June 2026 and valid through December 31, 2028. The practical message for cloud service providers (CSPs): tighten boundary clarity, produce machine-readable evidence, and build repeatable, automation-backed control narratives now. **Key takeaways** - The **FedRAMP Authorization Act** (Dec 2022) codified FedRAMP in law and defines a FedRAMP authorization as a **certification** that a cloud product or service completed the FedRAMP process. - In 2026, FedRAMP uses **one label — "FedRAMP Certified"** — with no separate "FedRAMP Validated" designation for 20x vs. Rev 5 (per **NTC-0004**). - Baselines are now named as four **Certification Classes — A, B, C, and D** — replacing numbered "levels," to avoid confusion with the DoD Impact Level system. - The **Consolidated Rules for 2026 (CR26)** are scheduled for end of June 2026 and remain valid through **December 31, 2028**. - **FedRAMP 20x** has exited its pilots and entered **Phase 3**; the public submission pipeline is expected to open in **FY26 Q4 (July–September 2026)**, initially for Class A (Pilot), Class B (Low), and Class C (Moderate). - The direction of travel is clear: **continuous, automated validation** over point-in-time audits, and **machine-readable packages** over static narratives. ## What did the FedRAMP Authorization Act establish? The FedRAMP Authorization Act, enacted as part of the National Defense Authorization Act for Fiscal Year 2023 (**Public Law 117-263**, December 2022), put FedRAMP on a statutory footing for the first time. Before the Act, the program operated under a 2011 memorandum from the Federal CIO with no direct legal basis. The Act, together with **OMB Memorandum M-24-15** (2024), effectively redefined how FISMA applies to cloud services and re-established FedRAMP as the government-wide process for assessing and authorizing them. Two definitions from the Act now drive 2026 terminology. The Act defines a FedRAMP authorization as "a certification that a cloud computing product or service has completed a FedRAMP authorization process," and a FedRAMP authorization package as "the essential information that can be used by an agency to determine whether to authorize the operation of an information system." FedRAMP has leaned directly on this language: the certification produces a reusable package that agencies use to make their own risk decisions under the Risk Management Framework. A critical nuance: a FedRAMP Certification is **not** an agency Authority to Operate (ATO), and it is not a guarantee that a service is appropriate for a given FIPS 199 security category. FedRAMP produces reusable, vetted materials; the agency authorizing official still accepts the risk. If you are untangling these two concepts, see our breakdown of [FedRAMP Certified vs ATO](/blog/20x/fedramp-ready-vs-authorized). ## What has FedRAMP 20x changed in 2026? FedRAMP 20x is the modern, cloud-native approach to certification, and in 2026 it is in **Phase 3 — the move from pilots to a permanent, publicly available program**. FedRAMP describes Phase 3 as the final set of activities needed to formally stand up 20x Certification types, with the submission pipeline opening in FY26 Q4 and initial availability for Class A (Pilot), Class B (Low), and Class C (Moderate). The substantive shift is in *how* security is demonstrated. Rev 5 was "designed for extensive written narratives describing static security decisions." 20x is "designed for automated demonstration of secure configurations and practices." In Rev 5, an agency sponsor invests resources up front; in 20x, no agency sponsor is required and FedRAMP reviews initial requests directly. FedRAMP has reported that 20x pilot participants received authorization "in less than two months from start," versus the years of preparation typical under the legacy path. For CSPs, three 20x mechanisms matter most: - **Key Security Indicators (KSIs)** — concise, validatable statements of expected security capabilities (RFC-0006 for Phase One Low, RFC-0014 for Phase Two Moderate). These replace much of the prose-heavy control narrative with evidence that can be checked. - **Persistent / automatic validation** — once a goal is set and a measurement framework is defined, status should be "automatically enforced and validated without human input whenever possible," supporting continuous review rather than a point-in-time audit. - **Minimum Assessment Scope** (RFC-0005) — an updated, security-first approach to defining what is in the assessment boundary, replacing older boundary guidance. If you are operationalizing this, our guide on how to [automate KSI evidence](/blog/20x/fedramp-20x-ksi-evidence-automation) walks through turning KSIs into continuously collected, machine-readable proof. For dates and phase detail, see the [FedRAMP 20x roadmap and key dates](/blog/20x/fedramp-20x-roadmap-2026). ## What's the new terminology — FedRAMP Certified and Classes A–D? The biggest naming change of 2026 came from **RFC-0020 (FedRAMP Authorization Designations)** and its outcome notice, **NTC-0004** (published February 25, 2026). The goal was to end the long-running confusion between "FedRAMP authorization" and an agency "authorization to operate." Three decisions stand out. First, there is now a **single official label for all FedRAMP authorizations: FedRAMP Certification / FedRAMP Certified.** FedRAMP explicitly decided *not* to create separate designations such as "FedRAMP Validated" for 20x versus Rev 5, agreeing with commenters that doing so would add procurement confusion. The Marketplace will instead use filters to distinguish the underlying paths. Second, baselines are no longer "levels" or numbers. Each baseline now maps to a **FedRAMP Certification Class (A, B, C, or D)**. FedRAMP dropped numbered levels specifically to avoid collision with the DoD/DoW Impact Level (IL) system, and to signal that the class defines the *scope and depth of the assessment*, not the total security or quality of the service. Third, FedRAMP kept **four baselines** with only minor changes, and provided a mapping for the transition period: | Certification Class | Maps to (Rev 5) | Notes | | --- | --- | --- | | **Class A** | New pilot baseline | Smaller initial information burden; entry point, also a 20x option | | **Class B** | Current LI-SaaS + Low | Light-use / smaller-footprint services; 20x option | | **Class C** | Current Moderate | The common target for SaaS used broadly by agencies; 20x option | | **Class D** | Current High | High-impact systems; not an initial 20x submission path | > Source: [FedRAMP NTC-0004 — Initial Outcome from RFC-0020](https://www.fedramp.gov/notices/0004/) NTC-0004 stresses that these labels **do not change the underlying requirements** — they relabel existing baselines so the names better reflect FedRAMP's statutory role. Old and new labels will be linked during a transition period, with full detail in CR26. For more on how classes work in practice, our [FedRAMP Marketplace](/blog/rev5/fedramp-marketplace-explained) explainer covers how authorized offerings are listed and filtered. ## What is the Consolidated Rules for 2026 (CR26)? The **Consolidated Rules for 2026 (CR26)** is the document that pulls the new rules together. Per NTC-0004 and the Phase 3 page, FedRAMP plans to publish CR26 **by the end of June 2026 (FY26 Q3)**, and the rules will be **valid through December 31, 2028**. CR26 is expected to contain all the requirements for FedRAMP 20x and to formalize the Class A/B/C/D labels, the transition mapping, and the relationship between 20x and Rev 5 baselines. A few things remain in flux as of this writing and should be confirmed against CR26 when it publishes: the exact requirement deltas per class, the timeline and mechanics for Class D / High under 20x (signaled for a later phase), and the precise transition rules linking old and new labels. Treat anything beyond what FedRAMP has published in RFCs and notices as directional, not final. ## What should CSPs do next? The actions below follow directly from the published direction: automation, machine-readable evidence, and boundary clarity. The table maps each change to its practical implication and a concrete next step. | Change | What it means | CSP action | | --- | --- | --- | | Single "FedRAMP Certified" label (NTC-0004) | No more "Validated" vs "Authorized" split; one term in contracts and marketing | Update sales, security, and procurement language to "FedRAMP Certified"; stop using "FedRAMP Validated" | | Classes A–D replace numbered levels | Baseline names describe assessment depth, not security quality or IL | Re-map your target baseline (e.g., Moderate → Class C); brief teams so no one confuses Class with DoD IL | | CR26 due end of June 2026, valid to Dec 31 2028 | A single rulebook with a defined validity window | Read CR26 on release; align your roadmap to the 2026–2028 window | | 20x in Phase 3; pipeline opens FY26 Q4 | Public submissions for Class A/B/C become possible this fiscal year | Decide your path now; if pursuing 20x, target the pipeline opening window | | Automatic / persistent validation | Continuous proof beats point-in-time audits | Stand up continuous evidence collection for KSIs; instrument controls to emit status automatically | | Machine-readable packages (RFC-0024) | Agencies ingest authorization data with tooling | Produce OSCAL/machine-readable artifacts, not just PDFs | | Minimum Assessment Scope (RFC-0005) | Security-first boundary definition | Re-examine and tighten your boundary; document scope clearly and defensibly | ### A first-hand view: where teams actually get stuck In our work helping CSPs prepare 20x evidence, the friction is rarely the security capability itself — it is proving it *continuously and machine-readably*. Teams that previously wrote a paragraph asserting, for example, that MFA is enforced now need an automated check that emits the enforced state on a schedule and survives a reviewer querying it months later. The CSPs that move fastest are the ones that treat each KSI as a small, testable assertion wired to live telemetry from their cloud and security tooling, then store the result in a structured, reusable format. That is the difference between a narrative you re-litigate every audit and a control story that maintains itself. Boundera was built around exactly this loop: map KSIs to evidence sources, validate continuously, and keep the package machine-readable from day one. ## Frequently asked questions ### Is "FedRAMP Validated" still a thing in 2026? No. Per NTC-0004, FedRAMP decided against a separate "FedRAMP Validated" designation. There is one label — **FedRAMP Certified** — for both 20x and Rev 5 paths. The Marketplace uses filters, not separate labels, to distinguish the paths. ### What's the difference between a FedRAMP Certification and an agency ATO? A FedRAMP Certification is a vetted, reusable authorization package. An agency ATO is a specific agency's decision to accept the risk of operating that service in its environment at a chosen FIPS 199 category. FedRAMP does not make the agency's risk decision for it; the certification just makes that decision far easier and reusable. ### What do Classes A, B, C, and D map to? Per NTC-0004, Class A is a new pilot baseline, Class B covers the current LI-SaaS and Low baselines, Class C is the current Moderate baseline, and Class D is the current High baseline. The four baselines themselves change only minimally; the labels are what's new. ### When is CR26 released and how long is it valid? FedRAMP plans to publish the Consolidated Rules for 2026 by the end of June 2026 (FY26 Q3). The rules are valid through December 31, 2028. ### When can I submit a FedRAMP 20x package? FedRAMP 20x is in Phase 3. The pilots are over, and the public submission pipeline is expected to open in FY26 Q4 (July–September 2026), initially for Class A (Pilot), Class B (Low), and Class C (Moderate). ### Does the Authorization Act require continuous monitoring? The Act and OMB M-24-15 push FedRAMP toward continuous, automated assurance, and 20x operationalizes this through persistent validation and KSIs. The exact continuous-monitoring requirements per class will be detailed in CR26 and related standards, so confirm specifics there. ### Should I pursue Rev 5 or 20x right now? It depends on your timeline, baseline, and whether you have an agency relationship. 20x offers a faster, automation-first path without an agency sponsor; Rev 5 remains available and is the only current route to a High (Class D) profile. Confirm the Class D / High 20x timeline in CR26 before committing. ### Did the new labels change FedRAMP requirements? No. NTC-0004 is explicit that the new labels relabel existing baselines and do not change the underlying requirements. The intent is to reduce confusion about what a FedRAMP Certification means, not to raise or lower the bar. ## Sources - [FedRAMP 20x Overview — fedramp.gov/20x](https://www.fedramp.gov/20x/) - [FedRAMP 20x Phase 3 — fedramp.gov/20x/phases/3](https://www.fedramp.gov/20x/phases/3/) - [NTC-0004: Initial Outcome from RFC-0020 (FedRAMP Authorization Designations)](https://www.fedramp.gov/notices/0004/) - [RFC-0020: FedRAMP Authorization Designations](https://www.fedramp.gov/rfcs/0020/) - [FedRAMP Requests for Comment (RFC index)](https://www.fedramp.gov/rfcs/) - [FedRAMP Authorization Act — Public Law 117-263 (congress.gov)](https://www.congress.gov/bill/117th-congress/house-bill/7776) --- _Last updated: June 2026. Written by the Boundera team. Boundera is an AI copilot for FedRAMP._ ### How Long Does FedRAMP Authorization Really Take? - URL: https://boundera.io/blog/rev5/how-long-does-fedramp-authorization-take - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2025-02-21T12:00:00.000Z - Updated: 2026-06-17T20:42:57Z - Reading time: 11 minutes - Main question: How long does FedRAMP authorization actually take from planning through ATO? - TL;DR: Most CSPs should expect 9 to 18+ months. The biggest timeline risks are unclear scope, slow SSP drafting, scattered evidence, and remediation churn. - Excerpt: A realistic look at the phases, bottlenecks, and timeline drivers behind a first FedRAMP authorization. # How Long Does FedRAMP Authorization Really Take? If you ask ten people how long FedRAMP takes, you’ll usually hear some version of: “plan for 12–18 months.” That’s not wrong, but it’s not very useful either. The better question is: **what actually drives the FedRAMP timeline**, and what can a CSP or consultant do to shrink it? This guide breaks the journey into realistic phases, explains where time really goes, and shows how better preparation and automation can pull the date of your ATO closer instead of letting it drift further away. ## The short answer: 9–18+ months for most CSPs For a cloud service provider that is serious about getting authorized, a realistic expectation is: - **Pre-readiness & strategy:** 1–3 months - **Readiness & control implementation:** 3–6 months - **Documentation & package build (SSP, attachments):** 3–6 months - **3PAO assessment & SAR:** 1–3 months - **Authorization decision & remediation:** 1–3 months These phases overlap, and the critical path depends heavily on your starting point. A security-mature SaaS with strong documentation can move faster; a team treating FedRAMP as its first serious security program will feel every month of the journey. ## Phase 0: Strategy and go/no-go (1–3 months) Before you “start FedRAMP,” you should answer a simpler question: **why are we doing this at all?** - Which federal agencies or programs are we targeting? - What impact level do we need (Low, Moderate, High, LI-SaaS)? - Are we aiming for an **Agency ATO** or longer, more complex **JAB authorization** path? - Do we have the engineering and security capacity to sustain FedRAMP, not just achieve it? Good strategy work at this stage saves months later by preventing mid-stream scope changes like “we actually need a different impact level” or “this architecture won’t support our target customers.” ## Phase 1: Readiness and groundwork (2–4 months) Readiness is where you discover how far your current environment is from the FedRAMP baseline. Typical activities: - System boundary definition and data flow diagrams - Initial gap assessment against the appropriate FedRAMP baseline - Policy and procedure review (or creation) - Early conversations with potential [3PAOs](/blog/rev5/fedramp-3pao-assessors) and agency sponsors **Where time disappears:** - Unclear or shifting system boundaries - Debates over multi-tenant vs dedicated architecture for federal customers - Underestimating the number of control gaps that must be addressed before assessment Many CSPs rush through readiness to “get started” and then discover those same issues again—this time under a microscope—during the formal assessment. ## Phase 2: Control implementation and hardening (3–6 months) Once you know your gaps, you have to close them. This phase includes: - Implementing missing security controls and technical safeguards - Hardening cloud environments to meet FedRAMP baselines - Rolling out new processes: incident response, change control, access reviews, etc. - Building logging, monitoring, and vulnerability management workflows In reality, this looks like a lot of engineering work: - Refactoring IAM and network architectures - Enabling encryption where it was optional before - Building stronger backup, DR, and availability guarantees - Centralizing logs and standing up a SIEM or log analytics solution Teams often underestimate the time it takes for real changes to make it through design, implementation, testing, and rollout—especially in production environments that already support paying customers. ## Phase 3: Documentation and SSP build (3–6 months) This is where FedRAMP often feels slowest: **writing and refining the documentation that explains what you built.** The biggest artifact here is the **System Security Plan (SSP)**, including: - System description, boundary, and architecture - Component inventory and interconnections - Detailed control implementation narratives for every applicable control and enhancement - Supporting plans and procedures referenced by the SSP Even for a well-designed system, capturing that reality in a way that assessors and Authorizing Officials can follow is a heavy lift. Most CSPs underestimate: - How long detailed, control-by-control narratives take to write - How many iterations are needed to align architecture diagrams, text, and reality - How much time is wasted hunting for evidence and linking it to controls For many teams, this phase alone can consume six months or more if done manually and in isolation from engineering. ## Phase 4: 3PAO assessment and SAR (1–3 months) With a reasonably mature SSP and environment, the 3PAO will finalize the **Security Assessment Plan (SAP)** and execute testing. This includes: - Interviews and evidence review - Technical testing (vulnerability scans, configuration reviews, control sampling) - Validation that what is described in the SSP matches reality - Drafting and finalizing the **Security Assessment Report (SAR)** The pure calendar time here is often shorter than earlier phases, but you are constrained by: - 3PAO scheduling and resource availability - How often you can safely schedule production testing windows - How quickly you can respond to requests for clarifications and additional evidence A prepared team with clean documentation and centralized evidence can move through this phase much more smoothly than a team still writing their SSP while the 3PAO is trying to test against it. ## Phase 5: Authorization decision and remediation (1–3 months) After the SAR is complete, your prospective Authorizing Official (or the JAB) reviews the package: - SSP and attachments - SAP and SAR - POA&M with identified weaknesses and remediation plans At this stage, the key questions are: - Do the documented risks align with the agency’s risk tolerance? - Are the remediation plans in the POA&M credible and time-bound? - Is there enough evidence to support the stated control implementations? Back-and-forth at this stage is normal, but extended delays often trace back to earlier issues: vague SSP content, inconsistent evidence, or a POA&M that doesn’t clearly show how and when gaps will be closed. ## What really slows FedRAMP down Across CSPs and consultants, the biggest timeline killers tend to look like this: 1. **Starting without a clear boundary.** You can’t document or secure what you can’t draw. 2. **Writing the SSP too late.** Treating documentation as an afterthought instead of a first-class artifact. 3. **Evidence chaos.** Screenshots and files scattered across tickets, wiki pages, and individual laptops. 4. **Wishful scheduling.** Assuming engineering can absorb all remediation work “on the side.” 5. **One-person bottlenecks.** A single SME owns the SSP, control mapping, and all responses to the 3PAO. The FedRAMP process itself is demanding, but most of the pain comes from these practical, day-to-day realities rather than the templates. ## Where FedRAMP timelines can be shortened The good news: not every part of the journey is locked in. CSPs and their consultants can pull on a few big levers: - **Do [real readiness](/blog/rev5/fedramp-readiness-assessment), not just a checkbox.** Invest early in boundary definition, architecture clarity, and realistic gap assessment. - **Parallelize work.** Don’t wait for “perfect” architecture before starting SSP drafting; iterate in lockstep. - **Standardize evidence.** Choose systems of record for logs, tickets, and artifacts and stick to them. - **Treat documentation as code.** Version control your SSP, templates, and diagrams; review them like you would code. - **Use automation wherever possible.** Especially for evidence collection, control mapping, and first-draft narratives. ## How automation and AI can save months Much of the FedRAMP calendar time isn’t spent on deep security work, it’s spent on **searching, copying, and re-phrasing** information you already have: - Pulling configuration and logging details from AWS, Azure, GCP, or your CI/CD pipelines - Describing the same technical reality dozens of times across control narratives - Keeping POA&M items and SSP descriptions in sync as changes roll out Modern tools can help by: - Automatically **[collecting evidence](/blog/20x/fedramp-20x-ksi-evidence-automation)** from your cloud, identity, and monitoring systems - **Mapping controls** to what you already do in your environment - Generating **first-draft narratives** that engineers and compliance leads can refine instead of writing from scratch - Keeping **POA&M items tied to real tickets** and infrastructure changes instead of isolated spreadsheets The exact number of months saved will vary, but teams that invest early in automation usually feel the difference in the SSP phase and every assessment after the first one. ## What is a realistic best case? In practice, a “best case” FedRAMP timeline looks something like this: - You already have strong security practices, policies, and monitoring in place. - Your architecture is well-documented, and your boundary is clear. - You centralize evidence and treat documentation as a living artifact. - You use automation to keep SSP content and evidence in sync with your real environment. Under those conditions, it is possible to move from serious start to ATO in roughly **6–9 months**. It’s still a heavy lift—but it feels like running a disciplined project rather than pushing a boulder uphill. ## Bringing it all together When someone says “FedRAMP takes 12–18 months,” what they are really capturing is a mix of: - Time spent deciding what you’re actually building for federal customers - Time spent designing and implementing the right controls - Time spent turning that reality into an SSP that assessors can understand - Time spent coordinating with a 3PAO and agency or JAB - Time spent fixing what the assessment uncovered You can’t control every part of that, but you have more influence than it might seem at first glance. The earlier you invest in clarity, documentation quality, and evidence automation, the closer your target ATO date moves toward you instead of receding into the distance. ### FedRAMP Documentation Explained: SSP, SAP, SAR, and POA&M - URL: https://boundera.io/blog/rev5/fedramp-documentation-ssp-sap-sar-poam - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2025-02-07T12:00:00.000Z - Updated: 2026-06-17T20:42:56Z - Reading time: 13 minutes - Main question: What FedRAMP documents do CSPs need, and how do the SSP, SAP, SAR, and POA&M fit together? - TL;DR: Most delays come from weak SSPs, missing evidence links, and poorly maintained POA&Ms rather than the assessment itself. - Excerpt: A practical guide to the core FedRAMP documents and how they fit together in the authorization process. ## FedRAMP Documentation Explained: SSP, SAP, SAR, and POA&M The FedRAMP process can feel overwhelming, but underneath the acronyms and templates it’s really a story about four core documents working together: - **SSP** – System Security Plan (how your system works and how you implemented controls) - **SAP** – Security Assessment Plan (how the 3PAO will test your system) - **SAR** – Security Assessment Report (what the assessment found) - **POA&M** – Plan of Action and Milestones (how you will fix the gaps) If you understand these four artifacts and how they relate, the rest of FedRAMP documentation starts to make sense. ## The FedRAMP package at a glance A typical FedRAMP authorization package includes many files, but the “spine” looks like this: Document Owner Primary purpose **SSP** (System Security Plan) CSP Describes the system, boundary, and control implementation details. **SAP** (Security Assessment Plan) 3PAO Defines how the assessment will be performed and what will be tested. **SAR** (Security Assessment Report) 3PAO Documents the results of testing, including findings and residual risk. **POA&M** (Plan of Action and Milestones) CSP (with 3PAO input) Tracks identified weaknesses, remediation plans, and due dates. These documents are not one-off deliverables. They are living artifacts that drive authorization _and_ continuous monitoring afterward. ## The System Security Plan (SSP) The **SSP** is the centerpiece of your FedRAMP package. It answers the big questions: - What is this system? - Where does it live (boundary, components, environments)? - What data does it process and at what impact level? - How are FedRAMP/NIST 800-53 controls implemented in practice? ### What goes inside the SSP? Every FedRAMP template has its own structure, but you can expect sections like: - System identification and contacts - System categorization and impact level - Architecture, data flows, and network diagrams - System environment and inventory - Interconnections and external dependencies - Laws, regulations, and policies - Control implementation summary - **Appendix A – Detailed control implementation narratives** - Supporting appendices (incident response plan, configuration management plan, ISCP, etc.) In practice, Appendix A usually consumes the most time: you must write a clear, specific narrative for each applicable FedRAMP control and enhancement. Related: [How to Convert Your SSP to OSCAL](/blog/20x/ssp-to-oscal-guide). ### What a good control narrative looks like Strong control descriptions answer five questions: - **HOW** is the control implemented? (mechanism, process, configuration) - **WHAT** specific tools or components are involved? - **WHO** is responsible for implementing and monitoring it? - **WHEN** does the activity happen (frequency, triggers)? - **WHERE** in the architecture or environment does it apply? Compare: - **Weak:** “We log security events and review them regularly.” - **Strong:** “All AWS CloudTrail events for production accounts are forwarded to a centralized logging account and ingested into our SIEM. The Security Operations team reviews daily alerts and weekly trend reports, with documented escalation procedures for suspected incidents.” The second example gives the assessor enough detail to test and trace the implementation. ### Common SSP pitfalls 1. **Copy-pasted language** from generic templates or other companies’ SSPs. 2. **Vague statements** (“we follow industry best practices”) without specifics. 3. **Inconsistent narratives** (diagrams and text describe different architectures). 4. **Missing evidence references** for key controls (no way to verify the claims). When the SSP is weak, the 3PAO spends more time interpreting and asking questions. That is where schedules and budgets start to slip. ## The Security Assessment Plan (SAP) The **Security Assessment Plan** is produced by the 3PAO. It explains: - What will be tested - How it will be tested (methods, tools, sampling) - Roles and responsibilities - Schedule and logistics You can think of the SAP as the “exam syllabus” for your system. It is heavily informed by your SSP: the better your system and controls are described, the easier it is for the 3PAO to define a targeted, realistic plan. ### Typical contents of a SAP - Assessment scope and boundary - Applicable baselines and overlays - Test procedures for technical, operational, and management controls - Sampling strategy (systems, accounts, records) - Rules of engagement (what is and isn’t allowed) - Deliverables and timelines While the 3PAO owns the SAP, CSPs should review it carefully to confirm that scope, assumptions, and logistics align with reality. ## The Security Assessment Report (SAR) The **SAR** is where the 3PAO documents what actually happened during the assessment and what they found. It turns the SAP and evidence into a structured risk picture for the Authorizing Official. ### What the SAR includes - Overview of the system and assessment approach - Summary of testing performed and evidence reviewed - Control-by-control results (satisfied, not satisfied, partially satisfied) - Vulnerability scan results and analysis - Detailed findings (weaknesses, issues, and residual risks) - Recommendations and overall risk determination From a CSP perspective, the SAR is where many of your future POA&M items are born. Each significant weakness or vulnerability identified in the SAR should map to one or more POA&M entries with a clear remediation path. ## The Plan of Action and Milestones (POA&M) The **POA&M** is the FedRAMP world’s to-do list. It tracks: - Every significant finding or weakness - Associated assets and controls - Root cause or description - Planned corrective actions - Owners and due dates - Status (open, in progress, closed) Unlike the SAR, which is tied to a specific assessment, the POA&M is **continuous**. It is updated as: - New findings are discovered (from scans, incidents, changes) - Existing findings are mitigated or downgraded - Remediation efforts slip or change scope ### What makes a good POA&M? - **Traceability:** each item links back to a control, asset, and source (scan ID, SAR finding, ticket). - **Realistic dates:** aggressive but achievable milestones that match engineering capacity. - **Clear ownership:** a named team or person, not just “Security”. - **Consistent updates:** status changes and notes that match reality. Authorizing Officials pay close attention to the POA&M. A large number of open items is not automatically a problem; unowned and stale items are. ## How the SSP, SAP, SAR, and POA&M work together You can think of the documents as a pipeline: 1. **SSP:** “Here is how our system and controls are designed and implemented.” 2. **SAP:** “Here is how we will verify that what you claimed in the SSP is actually true.” 3. **SAR:** “Here is what we found when we executed the SAP against your system.” 4. **POA&M:** “Here is how we plan to address the weaknesses identified in the SAR and during operations.” When these artifacts are aligned and kept in sync, the authorization process feels coherent. When they diverge—say, the SSP describes controls that aren’t implemented, or the POA&M doesn’t reflect current weaknesses—trust erodes and friction increases. ## Other important FedRAMP documents to know Beyond the “big four,” you’ll encounter several other recurring artifacts: - **CRM (Customer Responsibility Matrix):** clarifies which controls are owned by the CSP versus the federal customer. - **ConMon documentation:** procedures and artifacts for [continuous monitoring](/blog/rev5/fedramp-conmon-checklist), including reporting cadence and metrics. - **Policies and plans:** incident response plan, configuration management plan, contingency plan, and others referenced in the SSP. Many of these are referenced or partially embedded inside the SSP but often exist as separate maintained documents in your internal systems. ## Where CSPs and consultants lose time The most expensive documentation problems almost always rhyme: 1. **Vague or generic SSP content** that doesn’t match the real architecture. 2. **Evidence scattered across tools** with no clear mapping to controls or narratives. 3. **POA&Ms that live in spreadsheets** and are rarely updated until a reporting deadline. 4. **Inconsistent stories** between SSP diagrams, text, and what the 3PAO sees during testing. By the time issues show up in the SAR, it’s much more expensive to fix them than if the underlying documentation and evidence flows had been designed thoughtfully at the beginning. ## How to approach FedRAMP documentation more strategically - **Treat the SSP as a product, not a form.** It should explain your system clearly enough that a new engineer or assessor could understand how it works. - **Design evidence flows early.** Decide where control evidence will live and how it will be kept current. - **Align documentation with reality.** Update your SSP, architecture diagrams, and narratives when your system changes—not just before assessments. - **Integrate POA&M management with your existing workflows.** Map findings to tickets, owners, and sprints instead of letting them sit in an isolated spreadsheet. ## Bringing it all together You don’t have to love paperwork to be successful with FedRAMP, but you do need to respect the role documentation plays in the process. The SSP, SAP, SAR, and POA&M are how you communicate design, risk, and remediation to assessors and Authorizing Officials. Get those four right—and keep them aligned—and you avoid many of the delays and surprises that make FedRAMP feel painful. Treat them as living artifacts tied directly to your architecture, operations, and engineering workflows, and the authorization process becomes much more predictable. ## How Boundera helps with these documents If you are a CSP or consultant, most of your time on FedRAMP documentation goes into keeping the SSP, SAR, and POA&M consistent and up to date. - **SSP automation:** Generate first-draft control narratives and keep them in sync with your actual cloud configuration. - **[Evidence mapping](/blog/20x/fedramp-20x-ksi-evidence-automation):** Link controls to real evidence from AWS, GitHub, Okta and other tools instead of chasing screenshots. - **Living POA&M:** Treat findings as tickets that are owned, tracked, and reported automatically instead of managing a static spreadsheet. The goal is simple: spend less time wrestling with Word and Excel, and more time actually improving your security program. ### FedRAMP Low vs Moderate vs High: Impact Levels and How to Choose - URL: https://boundera.io/blog/rev5/fedramp-low-moderate-high-impact-levels - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2025-01-29T12:00:00.000Z - Updated: 2026-06-17T20:42:55Z - Reading time: 11 minutes - Main question: How do I choose between FedRAMP Low, Moderate, and High for my cloud service? - TL;DR: Most SaaS providers targeting federal agencies end up at Moderate. Your data types, agency requirements, and system boundary should drive the decision. - Excerpt: A practical guide to FedRAMP impact levels, what they mean, and how to choose the right baseline for your cloud service. # FedRAMP Low vs Moderate vs High: Impact Levels and How to Choose _Last updated: December 2025_ **TL;DR:** FedRAMP impact levels (Low, Moderate, High) determine which security baseline you must meet. They’re based on **[FIPS 199](/blog/rev5/fedramp-fips-validated-crypto)** categorization and the potential impact of a loss of confidentiality, integrity, or availability. Most CSPs selling SaaS to federal agencies should expect **FedRAMP Moderate**, but the right answer depends on the data types you handle, your system boundary, and agency requirements. ## Why impact levels matter One of the first FedRAMP questions a buyer, consultant, or 3PAO will ask is: **“Are you going for Low, Moderate, or High?”** Your impact level affects: - **How many controls** you must implement and document - **How deep the assessment** will be - **Timeline and [cost](/blog/rev5/fedramp-cost-by-impact-level)** (labor + 3PAO effort) - **What types of agencies** can use your system and for what data ## Quick definitions - **FedRAMP Low:** for low-impact federal information where compromise would cause limited harm. - **FedRAMP Moderate:** the most common baseline for cloud services used by agencies; often associated with sensitive but unclassified information. - **FedRAMP High:** for the most sensitive unclassified data and mission-critical systems where compromise could cause severe harm. ## Control counts (what to expect) Exact control counts vary depending on baseline versions, parameters, and overlays, but typical expectations are: Baseline Typical control count Common use **Low** ~125 Public / low-risk data, limited harm if compromised **Moderate** ~325 Most SaaS offerings used by agencies **High** ~421 High-sensitivity / mission-critical unclassified systems ## What drives the impact level? (FIPS 199 in plain English) FedRAMP impact levels are derived from **FIPS 199**, which categorizes information systems based on the potential impact of a loss of: - **Confidentiality** (data exposure) - **Integrity** (unauthorized modification) - **Availability** (outage or denial of service) In practice, you choose the baseline by answering two questions: 1. **What data will agencies put in the system?** 2. **What could realistically go wrong if the system is compromised or unavailable?** ## How to choose the right FedRAMP baseline (step-by-step) ### Step 1: List the data types you will handle Be specific. Don’t just say “federal data.” Identify what the system stores, processes, or transmits: - User identity data (names, emails, roles) - Operational logs and audit trails - Documents (SSPs, POA&Ms, reports) - Security findings (vuln results, configurations) - Customer evidence artifacts and screenshots ### Step 2: Define your system boundary Your impact level applies to the **authorized system boundary**. If your product integrates with third-party systems (e.g., GitHub, AWS, Okta), you’ll need to decide: - What is inside your boundary (hosted, controlled, monitored by you) - What is outside your boundary (customer systems, external SaaS, inherited services) **Tip for CSPs:** A clean boundary definition avoids months of rework later in the SSP and assessment. ### Step 3: Map CIA impact (Low/Moderate/High) for each major function Think like an Authorizing Official: - **Confidentiality:** Would disclosure cause limited, serious, or severe harm? - **Integrity:** Would tampering create minor issues, major compliance failures, or severe mission impact? - **Availability:** Would downtime be annoying, disruptive to operations, or catastrophic? The resulting categorization typically drives you toward Low, Moderate, or High. ## Practical guidance: which level do you likely need? ### When FedRAMP Low is a fit - You truly handle **low-impact information** and your use case remains low-risk. - The agency confirms they will not place sensitive data in your platform. - Your service is informational, public-facing, or non-sensitive by nature. ### When FedRAMP Moderate is the default choice - You handle sensitive but unclassified data, common operational data, or materials that agencies treat as sensitive. - Your platform includes identity, access control, audit logging, and security workflows. - You want broad applicability across agencies without constantly defending a Low categorization. **Reality:** Most SaaS CSPs selling into the federal market should plan for Moderate unless they have a strong reason not to. ### When FedRAMP High is required - Your service supports highly sensitive federal missions. - The agency requires High due to the sensitivity of the information or operational risk. - Failure or compromise would have severe consequences. **Note:** FedRAMP High is significantly more demanding. Many companies build maturity with Moderate first unless they have a clear buyer requiring High. ## Where LI-SaaS fits (and where it doesn’t) **LI-SaaS** (Low Impact Software as a Service) is designed for certain low-impact SaaS offerings. It can reduce scope and streamline documentation, but it is not a shortcut for systems that will handle Moderate-level data. LI-SaaS tends to work best when: - The agency use case is clearly low-impact - The system is SaaS - The system does not process or store data that pushes categorization toward Moderate If your buyers are asking about CUI, Moderate, or deeper auditability, LI-SaaS is usually not the right path. ## Common mistakes CSPs make when choosing an impact level 1. **Picking Low “to start”** even though target agencies require Moderate (creates rework). 2. **Assuming the impact level is purely a product decision** (agency context matters). 3. **Not scoping the boundary early**, then discovering later that “out-of-boundary” services create control gaps. 4. **Ignoring availability impact** (mission-critical availability pushes categorization upward). ## How consultants and MSPs should use this If you help CSPs prepare FedRAMP packages, you can use this baseline decision as an early-stage checklist: - Confirm target agencies and expected data types - Draft a boundary statement and major components inventory - Create a first-pass FIPS 199 rationale - Identify “scope bombs” (external dependencies that complicate controls) ## What to do next - **If you’re early:** Draft your boundary, list data types, and build a first-pass categorization rationale. - **If you’re actively selling:** Ask prospects what impact level they require and align your roadmap accordingly. - **If you’re preparing documentation:** Make sure your SSP scope and CRM assumptions match your chosen baseline. **Optional shortcut:** Teams reduce weeks of back-and-forth by auto-inventorying their cloud resources and mapping evidence to baseline controls early. If you’re building toward Moderate, it’s worth [automating evidence collection](/blog/20x/fedramp-20x-ksi-evidence-automation) from day one. ## Summary Choosing between FedRAMP Low, Moderate, and High is not a guess — it’s a structured decision based on FIPS 199, your system boundary, the data types you handle, and agency expectations. In most cases, CSPs targeting federal buyers should plan for **Moderate** unless there’s a well-documented low-impact use case. ### The Complete FedRAMP Authorization Guide (2025) - URL: https://boundera.io/blog/rev5/complete-fedramp-authorization-guide-2025 - Program: FedRAMP Rev 5 - Category: FedRAMP Guides - Published: 2025-01-15T12:00:00.000Z - Updated: 2026-06-17T20:42:53Z - Reading time: 12 minutes - Main question: How do I get FedRAMP authorization in 2025? - TL;DR: FedRAMP authorization is required to sell cloud services to U.S. federal agencies. This guide explains timelines, costs, authorization paths, and common pitfalls. - Excerpt: A complete, end-to-end guide to FedRAMP authorization for cloud service providers. # The Complete FedRAMP Authorization Guide (2025) **Everything Cloud Service Providers Need to Know — From Readiness to ATO** > **TL;DR:** FedRAMP authorization is mandatory for selling cloud services to U.S. federal agencies. The traditional process takes **12–18 months and $250k–$500k**, but modern automation and AI can reduce timelines to **weeks instead of months**. This guide explains the process end-to-end, common pitfalls, costs, timelines, and how CSPs can approach FedRAMP strategically in 2025. * * * ## What Is FedRAMP? **FedRAMP (Federal Risk and Authorization Management Program)** is a U.S. government program that standardizes how cloud services are assessed, authorized, and continuously monitored for security. If your cloud product will store, process, or transmit **federal data**, FedRAMP authorization is **not optional**. FedRAMP is based on **NIST SP 800-53**, which defines hundreds of security controls covering access control, encryption, logging, incident response, and more. ## Who Needs FedRAMP? You need FedRAMP if you are: - A **Cloud Service Provider (SaaS, PaaS, IaaS)** - Selling to **U.S. federal agencies** - Handling **Federal Information** (Low, Moderate, or High impact) You **do not** need FedRAMP if: - You sell only to commercial customers - You do not host or process federal data ## FedRAMP Impact Levels (Low, Moderate, High) FedRAMP authorization is scoped by **impact level**, defined by **FIPS 199**. ### FedRAMP Low - ~125 controls - Public or low-risk data - Often used for marketing or public-facing systems ### FedRAMP Moderate (Most Common) - ~325 controls - Covers Controlled Unclassified Information (CUI) - Required for most SaaS products selling to agencies ### FedRAMP High - ~421 controls - Highly sensitive federal data - Longest and most expensive path **Most CSPs should expect FedRAMP Moderate.** ## FedRAMP Authorization Paths There are **two authorization paths**: ### 1\. Agency Authorization (Most Common) - Sponsored by a single federal agency - Faster and more flexible - Evidence can later be reused by other agencies ### 2\. JAB Authorization - Sponsored by the Joint Authorization Board (DoD, DHS, GSA) - Accepted government-wide - Longer timelines and higher scrutiny **Most startups and SaaS companies should pursue Agency ATO first.** ## The FedRAMP Authorization Process (Step-by-Step) ### Step 1: Readiness Assessment Before engaging a [3PAO](/blog/rev5/fedramp-3pao-assessors), CSPs typically perform a **[FedRAMP Readiness Assessment](/blog/rev5/fedramp-readiness-assessment)** to evaluate: - Architecture - Security tooling - Control maturity - Gaps against NIST 800-53 **Typical time:** 2–4 weeks ### Step 2: System Security Plan (SSP) Development The **SSP** is the core FedRAMP document (often **200–400 pages**). It describes: - System architecture - Boundaries - Control implementation for every NIST control - Customer vs provider responsibilities **Appendix A (control descriptions) is the hardest part.** **Traditional:** 6–9 months **With automation:** days to weeks ### Step 3: 3PAO Security Assessment A **Third-Party Assessment Organization (3PAO)** validates: - Control implementation - Evidence - Vulnerability findings Deliverables include: - SAR (Security Assessment Report) - POA&M (Plan of Action & Milestones) **Typical time:** 4–8 weeks ### Step 4: Remediation All findings must be: - Fixed - Documented - Tracked in POA&M This phase often causes delays due to poor evidence management. ### Step 5: Authorization (ATO) The Authorizing Official reviews the package and issues an **Authority to Operate (ATO)**. Once granted: - Your system is listed in the [FedRAMP Marketplace](/blog/rev5/fedramp-marketplace-explained) - Agencies can reuse your authorization ## How Long Does FedRAMP Take? Approach Timeline Traditional 12–18 months With automation 8–12 weeks (varies by maturity) ## How Much Does FedRAMP Cost? ### Traditional Costs - 3PAO: $50k–$150k - Internal labor: $200k–$350k - Consultants: optional but expensive **Total:** [$250k–$500k+](/blog/20x/fedramp-cost-2026) ### Modern, Automated Approach - Reduced documentation effort - Faster assessments - Lower internal labor cost **Savings:** 60–70% in both time and cost ## Common FedRAMP Pitfalls (and Why CSPs Fail) 1. **Starting too late** 2. **Underestimating SSP complexity** 3. **Poor evidence organization** 4. **Manual, copy-paste documentation** 5. **Ignoring continuous monitoring** FedRAMP is not “set it and forget it.” ## FedRAMP Continuous Monitoring (After ATO) After authorization, CSPs must: - Submit **monthly vulnerability scans** - Track POA&M items - Perform annual assessments - Report significant changes Many CSPs struggle **after** ATO due to manual processes. ## How Automation Changes FedRAMP Modern platforms can: - Auto-collect evidence from AWS, Azure, GCP, GitHub, Okta - Map infrastructure directly to NIST controls - Generate SSP Appendix A drafts - Maintain continuous compliance automatically This is how teams reduce: - Documentation time by **80–95%** - Assessment delays - Human error ## Is FedRAMP Worth It? FedRAMP is worth it if: - Federal agencies are part of your ICP - You want long-term government revenue - You treat security as a product feature FedRAMP is **not** worth it if: - You have no federal sales motion - You are unwilling to invest in security maturity ## Getting Started with FedRAMP If you are new to FedRAMP: 1. Confirm your target impact level 2. Perform a readiness assessment 3. Inventory your architecture 4. Decide on manual vs automated approach 5. Engage a 3PAO only when ready ## Final Thoughts FedRAMP is complex — but it does **not** need to be slow, expensive, or painful. CSPs that treat FedRAMP as an **engineering and automation problem** consistently: - Move faster - Spend less - Maintain compliance long-term ### Ready to See Where You Stand? Start with a **free FedRAMP readiness scan** and understand your gaps before engaging a 3PAO. * * * ## Recommended next reads - [FedRAMP Readiness Checklist (2025)](/blog/fedramp-readiness-checklist-2025) - [How Long Does FedRAMP Really Take? (2025)](/blog/how-long-does-fedramp-take-2025) - [FedRAMP Cost Breakdown: Real Numbers (2025)](/blog/fedramp-cost-breakdown-2025) - [How to Write SSP Appendix A (Without Losing Your Mind)](/blog/ssp-appendix-a-writing-guide-2025) - [FedRAMP Continuous Monitoring: What CSPs Miss](/blog/fedramp-continuous-monitoring-2025) * * * ## All Resources ### The FedRAMP 20x Executive Playbook - URL: https://boundera.io/resources/20x/fedramp-20x-executive-playbook - Program: FedRAMP 20x - Category: Guides & Playbooks - Type: guide - Format: PDF - Size: 180 KB - Updated: 2026-06-22T07:47:03.531156+00:00 - Description: A field guide to building a machine-readable FedRAMP 20x program: how to automate evidence and continuous validation without faking the attestation. Covers treating every check as a first-class object, deriving control status from live state, and keeping humans on the attestations machines can't make. - Best for: CSP founders and security leads planning a FedRAMP 20x authorization; Compliance engineers who want continuous validation, not screenshot collection; Teams deciding whether to build automation in-house or buy it - Outcomes: Why 20x's machine-readable model finally makes real automation possible; How to model every validator and check as a first-class object you can query; Deriving control status from live system state on read, not point-in-time snapshots; Running remediation as a pipeline, and where the 'honesty firewall' keeps humans in the loop - Tags: Automation, Continuous Monitoring, FedRAMP 20x, KSI, OSCAL, Playbook ### SSP Appendix A - Moderate FedRAMP Security Controls - URL: https://boundera.io/resources/rev5/ssp-appendix-a-moderate-fedramp - Program: FedRAMP Rev 5 - Category: Templates - Type: template - Format: DOCX - Size: 499 KB - Updated: 2026-06-22T07:26:15.457740+00:00 - Description: Complete System Security Plan Appendix A template for FedRAMP Moderate baseline. Includes all 325 required security controls with implementation guidance and examples. - Best for: Teams drafting their first SSP; Consultants building a client package - Outcomes: Appendix A structure aligned to Moderate controls; Implementation prompt scaffolding for faster drafting; Cleaner handoff into review and 3PAO prep - Tags: FedRAMP, Moderate, SSP, Templates ### FedRAMP Moderate Readiness Assessment Report (RAR) Template - URL: https://boundera.io/resources/rev5/fedramp-moderate-rar-template - Program: FedRAMP Rev 5 - Category: Checklists - Type: template - Format: DOCX - Size: 129 KB - Updated: 2026-06-22T07:26:15.452045+00:00 - Description: Readiness Assessment Report template for FedRAMP Moderate. Use this to assess your organization's preparedness before starting formal authorization. - Best for: Moderate-bound systems; Teams preparing a readiness review - Outcomes: RAR drafting template; Clear readiness gap documentation; Better internal go/no-go decisions - Tags: FedRAMP, Moderate, RAR, Templates ### FedRAMP High Baseline System Security Plan (SSP) - URL: https://boundera.io/resources/rev5/fedramp-high-baseline-ssp - Program: FedRAMP Rev 5 - Category: Templates - Type: template - Format: DOCX - Size: 215 KB - Updated: 2026-06-22T07:26:15.442700+00:00 - Description: Complete SSP template for FedRAMP High baseline with 421 security controls. Required for systems processing highly sensitive federal data. - Best for: High-impact environments; Teams already operating at Moderate - Outcomes: High-baseline narrative structure; Faster control-family ownership mapping; Reduced blank-page drafting time - Tags: FedRAMP, High, SSP, Templates ### FedRAMP Initial Authorization Package Checklist - URL: https://boundera.io/resources/rev5/fedramp-authorization-package-checklist - Program: FedRAMP Rev 5 - Category: Checklists - Type: checklist - Format: XLSX - Size: 21 KB - Updated: 2026-06-22T07:26:15.438492+00:00 - Description: Comprehensive checklist of all required documents for FedRAMP initial authorization. Ensure your package is complete before submission. - Best for: Program managers; Teams approaching package submission - Outcomes: Submission-readiness checklist; Clear package ownership by artifact; Fewer last-minute document gaps - Tags: Checklist, FedRAMP, Templates ### CSP Authorization Playbook - URL: https://boundera.io/resources/rev5/csp-authorization-playbook - Program: FedRAMP Rev 5 - Category: Guides & Playbooks - Type: guide - Format: PDF - Size: 1.4 MB - Updated: 2026-06-22T07:26:15.434120+00:00 - Description: Step-by-step playbook for Cloud Service Providers pursuing FedRAMP authorization. Covers Agency and JAB paths with detailed guidance. - Best for: Founders; Compliance leads; Delivery teams - Outcomes: Milestone-based program plan; Role handoffs for consultants, 3PAOs, and internal teams; Better sequencing from readiness through ATO - Tags: FedRAMP, Playbook ### FedRAMP 20x Incident Reports (IIR, OIR, FIR) Example - URL: https://boundera.io/resources/20x/fedramp-20x-incident-report-examples - Program: FedRAMP 20x - Category: Certification Data Examples - Type: example - Format: ZIP - Size: 5 KB - Updated: 2026-08-04T15:47:16.870689+00:00 - Description: Follow fictional incident information from Initial through Ongoing and Final reports, including timelines, PAIN ratings, impact, activity, recovery, and root cause. - Best for: Incident response and communication teams; Security operations engineers; Agency and assessor incident reviewers - Outcomes: Understand how IIR, OIR, and FIR content evolves; See how PAIN information and timelines are carried forward; Compare a nested report index with individual schema documents; Prototype incident communication and update workflows - Tags: FedRAMP 20x, FedRAMP Incident Report, Final Incident Report (FIR), Incident Communication, Initial Incident Report (IIR), Ongoing Incident Report (OIR), PAIN Rating - Included formats: HTML, JSON - Important notice: These files are synthetic FedRAMP 20x worked-example data generated on July 27, 2026. They are not an official FedRAMP template, a live production or security disclosure, evidence of Boundera's certification status, an agency authorization, or an endorsement. Check the FedRAMP Marketplace for current status, and adapt and independently validate the example before use. ## From initial report to final report This pair contains four synthetic incident-report records. Three describe one fictional credential-stuffing scenario as it moves through an Initial Incident Report, an Ongoing Incident Report, and a Final Incident Report. The fourth is an Initial Incident Report for a separate fictional anomalous-egress scenario. The IIR demonstrates early information such as the federal incident coordinator, provider tracking ID, incident description, detection timeline, Potential Agency Impact N-rating (PAIN), functional impact, and recovery plan. The OIR adds observed activity and indicators of compromise as the investigation develops. The FIR supplies final resolution information, root cause, and response and recovery activities. Reading the sequence shows which fields should persist, which estimates can change, and how later reports should update earlier uncertainty instead of silently replacing it. ## Structure and practical use The outer `reports` envelope is an index, not a standalone FedRAMP report schema. Each nested `report` states its document schema and report type. Validation and storage workflows should preserve the filed report, its filing time, and the relationship among updates sharing a provider tracking identifier. Use JSON to prototype ingestion, correlation, deadline tracking, and reviewer alerts. Use HTML to test whether a person can distinguish known facts from estimates, locate changed PAIN information, and understand current recovery status. Current FedRAMP terminology is Incident Evaluation and Communication; these examples do not replace official reporting procedures, federal notification channels, or agency-specific requirements. ## Synthetic example and current status The incidents, accounts, telemetry, indicators, federal contacts, timelines, impacts, PAIN ratings, root causes, and response actions in these **2026-07-27** files are fictional. No listed incident occurred in Boundera production and none describes actual agency or customer data. Refer to the [official FedRAMP Marketplace record](https://www.fedramp.gov/marketplace/products/FR2628943633/) for current status. #### Frequently asked questions - What are IIR, OIR, and FIR? They are Initial, Ongoing, and Final Incident Reports used at different stages of incident communication. - What does PAIN mean? PAIN is the Potential Agency Impact N-rating used to communicate likely adverse impact on agency customers. - Did these incidents happen to Boundera? No. Every incident and related detail in the download is synthetic. ### FedRAMP 20x Significant Change Notification (SCN) Examples - URL: https://boundera.io/resources/20x/fedramp-20x-significant-change-notification-examples - Program: FedRAMP 20x - Category: Certification Data Examples - Type: example - Format: ZIP - Size: 5 KB - Updated: 2026-08-04T15:47:16.859105+00:00 - Description: Follow a synthetic transformative-change lifecycle and contrast it with a rough adaptive notification that demonstrates a completeness failure. - Best for: Change-management and security teams; Trust-center developers; Assessors and agency change reviewers - Outcomes: Follow transformative change communication across four stages; Distinguish transformative and adaptive change records; Identify vague, decision-poor content as a completeness anti-pattern; Understand the difference between an index envelope and nested schema documents - Tags: Adaptive Change, Change Impact Analysis, Change Notification Example, FedRAMP 20x, SCN-CSO-HIS, Significant Change Notification (SCN), Transformative Change - Included formats: HTML, JSON - Important notice: These files are synthetic FedRAMP 20x worked-example data generated on July 27, 2026. They are not an official FedRAMP template, a live production or security disclosure, evidence of Boundera's certification status, an agency authorization, or an endorsement. Check the FedRAMP Marketplace for current status, and adapt and independently validate the example before use. ## Following a significant change lifecycle This worked pair indexes five synthetic Significant Change Notifications from a trailing 12-month window. Four notices follow one fictional transformative change through initial plans, final plans, completion, and post-change verification. Together they show how reason, categorization, customer impact, impact analysis, milestones, approver, and affected KSIs can remain connected as a change progresses. The outer `notifications` envelope serves the records together; it is not itself a FedRAMP schema document. Each nested `notification` identifies its own document schema. That distinction matters when designing validation: validate each filed notification as a document and separately test the index behavior. ## The final item is a completeness anti-pattern The fifth record is a rough adaptive-change notice. It includes phrases such as `needed`, `okay`, `noot much`, and `Just needed for normal stuff`, plus a minimally described plan and approver. The download preserves that record exactly; it is **not recommended content**. Its educational value is demonstrating a completeness and decision-usefulness failure. A record can be serializable, or pass some structural checks, while still failing to explain why a change is adaptive, what customer responsibilities change, what risks were evaluated, how verification will occur, and whether the approver is appropriate. Compare the weak item with the four detailed transformative notices to build substantive quality checks alongside schema validation. Real notifications must reflect the actual offering and current rules. ## Synthetic example and current status Every topology, milestone, impact, KSI, approver, and notification in these **2026-07-27** files is synthetic. The examples were not sent by Boundera to FedRAMP or an agency and do not describe live architecture or production changes. Check the [official FedRAMP Marketplace record](https://www.fedramp.gov/marketplace/products/FR2628943633/) for current status. #### Frequently asked questions - Why is the fifth notification so vague? It is preserved as a completeness anti-pattern. It shows why structural validity alone is not enough. - Is the outer JSON index a FedRAMP schema document? No. The envelope indexes served-as-sent records; each nested notification identifies the schema against which it should be evaluated. - Should teams copy the detailed transformative notices verbatim? No. They are synthetic examples. Real notifications must reflect the actual offering, impacts, plan, verification, and current rules. ### FedRAMP 20x Historical VER Activity Example - URL: https://boundera.io/resources/20x/fedramp-20x-historical-vulnerability-activity-example - Program: FedRAMP 20x - Category: Certification Data Examples - Type: example - Format: ZIP - Size: 5 KB - Updated: 2026-08-04T15:47:16.847094+00:00 - Description: See how recent active and accepted vulnerability records can be assembled into an automation-friendly historical VER snapshot. - Best for: Security data-platform teams; Vulnerability program managers; Agency monitoring and automation teams - Outcomes: Understand the purpose of a historical VER retrieval view; Combine active and accepted records without losing their distinction; Prototype automated retrieval and status reconciliation; Recognize the difference between a snapshot and a full event history - Tags: Accepted Vulnerabilities, Active Vulnerabilities, Automated Retrieval, FedRAMP 20x, Historical VER Activity, Vulnerability Evaluation and Reporting (VER), Vulnerability History - Included formats: HTML, JSON - Important notice: These files are synthetic FedRAMP 20x worked-example data generated on July 27, 2026. They are not an official FedRAMP template, a live production or security disclosure, evidence of Boundera's certification status, an agency authorization, or an endorsement. Check the FedRAMP Marketplace for current status, and adapt and independently validate the example before use. ## A combined vulnerability snapshot FedRAMP calls this artifact Historical Vulnerability Evaluation and Reporting Activity. The worked pair combines three synthetic active vulnerability records and three synthetic accepted vulnerability records in one generated snapshot. The active collection carries detection, reachability, exploitability, evaluation, description, and rating fields. The accepted collection carries similar technical context plus acceptance rationale and senior-official acceptance. Keeping those groups separate lets consumers distinguish findings progressing through response work from risks being carried through an explicit acceptance decision. JSON is suited to automated retrieval, inventory reconciliation, and change detection; HTML makes the same snapshot readable without a consuming system. ## What history means here Use this example to design questions a retrieval workflow should answer: Which records are new? Which changed rating or disposition? Did an active item become accepted? Is an accepted item still present at the next cutoff? Does the human-readable output match the API response? The included file is a point-in-time aggregation, not a complete event ledger. It does not independently show every transition, rating change, mitigation, closure, or removal before generation. A production historical service may need dated snapshots, immutable change events, stable identifiers, and reconciliation rules so reviewers can reconstruct how each record evolved. Applicability and update cadence vary by Certification Class; confirm current requirements instead of inferring a cadence from this one dated example. ## Synthetic example and current status All vulnerabilities, timestamps, components, ratings, acceptance rationales, decisions, and officials in these **2026-07-27** files are fictional. The pair is not an export of Boundera's live vulnerability-management or production-security systems. Use the [official FedRAMP Marketplace record](https://www.fedramp.gov/marketplace/products/FR2628943633/) for current information. #### Frequently asked questions - How is this different from the Vulnerability Detail Report? It combines active and accepted records into one retrieval-oriented snapshot instead of reporting only the period's non-accepted findings. - Is this a complete vulnerability audit trail? No. It is a point-in-time snapshot, not a full sequence of every state transition. - Why provide JSON and HTML? JSON supports automation, while HTML gives reviewers a readable representation of the same snapshot. ### FedRAMP 20x Accepted Vulnerability Information Example - URL: https://boundera.io/resources/20x/fedramp-20x-accepted-vulnerability-information-example - Program: FedRAMP 20x - Category: Certification Data Examples - Type: example - Format: ZIP - Size: 4 KB - Updated: 2026-08-04T15:47:16.834988+00:00 - Description: Examine how accepted vulnerability records can pair technical evaluation fields with explicit rationale and accountable senior-official acceptance. - Best for: CISOs and risk owners; Vulnerability governance teams; Assessors and agency reviewers - Outcomes: Distinguish accepted vulnerabilities from ordinary active findings; Trace technical evaluation into a documented acceptance rationale; Model accountable decision and acceptance metadata; Design concise risk summaries for necessary parties - Tags: Accepted Vulnerability, Accepted Vulnerability Info (AVI), FedRAMP 20x, Risk Acceptance, Senior Official Acceptance, VER-RPT-AVI, Vulnerability Governance - Included formats: HTML, JSON - Important notice: These files are synthetic FedRAMP 20x worked-example data generated on July 27, 2026. They are not an official FedRAMP template, a live production or security disclosure, evidence of Boundera's certification status, an agency authorization, or an endorsement. Check the FedRAMP Marketplace for current status, and adapt and independently validate the example before use. ## What accepted vulnerability information adds This pair contains three synthetic accepted vulnerability records. Each begins with familiar vulnerability-detail fields—tracking identifier, detection and evaluation timing, internet reachability, likely exploitability, and rating—then adds an acceptance rationale and a senior-official acceptance record. The examples illustrate three fictional decision patterns: temporary compatibility with an agency integration, constrained local exploitability, and dependence on an upstream vendor without an available fix. They show how context might be explained; they are not recommended justifications or conclusions. FedRAMP's 2026 rules require a vulnerability that is not, or will not be, fully mitigated or remediated within 192 days of evaluation to be categorized as accepted. Categorization does not make the vulnerability safe, resolved, or exempt from scrutiny. ## Acceptance is an accountable risk decision A useful accepted-vulnerability record should make the residual risk understandable. Reviewers need to know what remains exposed, the likely impact on federal customer data, why remediation is not presently occurring, what mitigations constrain the risk, and who is accountable for the decision. Use this pair to test how technical and governance information stay connected across APIs and human-readable reports. When adapting the structure, verify dates and ratings, avoid vague rationale, document planned risk reduction, and revisit whether continued acceptance remains supportable as conditions change. The example must not be used to justify accepting a real finding; actual decisions require offering-specific evidence, current threat context, responsible disclosure, and applicable rules. ## Synthetic example and current status The vulnerabilities, technical conditions, agency dependency, mitigations, officials, approvals, and risk decisions in these **2026-07-27** files are fictional. They are not live Boundera security, production, agency, authorization, or certification facts. Check the [official FedRAMP Marketplace record](https://www.fedramp.gov/marketplace/products/FR2628943633/) for current status. #### Frequently asked questions - Does accepted mean a vulnerability is remediated? No. It means the residual risk is being carried under a documented and accountable decision. - Why does the 192-day period matter? Current rules require vulnerabilities that will not be fully mitigated or remediated within that period to be categorized as accepted. - Are the named officials and acceptance decisions real? No. They are synthetic example data and do not describe Boundera personnel or decisions. ### FedRAMP 20x Vulnerability Detail Report Example - URL: https://boundera.io/resources/20x/fedramp-20x-vulnerability-detail-report-example - Program: FedRAMP 20x - Category: Certification Data Examples - Type: example - Format: ZIP - Size: 3 KB - Updated: 2026-08-04T15:47:16.822997+00:00 - Description: Study three synthetic vulnerability records showing detection, internet reachability, likely exploitability, completed evaluation, and current rating fields. - Best for: Vulnerability-management teams; Security data engineers; Assessors and agency risk reviewers - Outcomes: Understand the fields around a detected vulnerability; Distinguish internet reachability from likely exploitability; Prototype vulnerability filtering and reviewer displays; Compare the example with current reporting requirements to find gaps - Tags: FedRAMP 20x, Internet-Reachable Vulnerability (IRV), JSON Example, Likely Exploitable Vulnerability (LEV), Potential Agency Impact, Vulnerability Detail Report (VDR), Vulnerability Reporting - Included formats: HTML, JSON - Important notice: These files are synthetic FedRAMP 20x worked-example data generated on July 27, 2026. They are not an official FedRAMP template, a live production or security disclosure, evidence of Boundera's certification status, an agency authorization, or an endorsement. Check the FedRAMP Marketplace for current status, and adapt and independently validate the example before use. ## What the report models This Vulnerability Detail Report pair contains three synthetic findings for the example reporting period. Each record includes a provider tracking identifier, detection time and source, a description, internet-reachability evaluation, likely-exploitability evaluation, evaluation completion time, and a current numeric rating. Those fields demonstrate an important FedRAMP 2026 distinction: internet reachability and likely exploitability are separate contextual evaluations. A vulnerable resource does not have to be directly internet-accessible to process a triggering internet-originated payload, and a scanner finding alone does not establish that exploitation is likely in the actual cloud service offering. The three records exercise different combinations of reachability, exploitability, and rating in JSON and HTML. ## How to evaluate the example Use the pair to prototype ingestion, validation, reporting, or reviewer experiences. A reader should be able to identify when a vulnerability was found, understand the provider's contextual evaluation, and follow changes in Potential Agency Impact over time. Current [Vulnerability Evaluation and Reporting rules](https://www.fedramp.gov/2026/providers/20x/rules/vulnerability-evaluation-and-reporting/) call for additional decision context where applicable, including historical and current ratings, evaluated reductions, expected next reductions, overdue status, supplementary risk information, and final disposition. Treat this compact sample as a starting point for gap analysis, not a complete production report. Public vulnerability content also requires responsible-disclosure review. ## Synthetic example and current status The CVEs, identifiers, scanner results, components, reachability decisions, exploitability decisions, ratings, and remediation narratives in these **2026-07-27** files are fictional. They do not describe live Boundera vulnerabilities or production security. Refer to the [official FedRAMP Marketplace record](https://www.fedramp.gov/marketplace/products/FR2628943633/) for current status. #### Frequently asked questions - Is internet-reachable the same as directly internet-accessible? No. The evaluation considers whether internet-originated input can reach and trigger the vulnerable condition, including through other components. - How does this differ from Accepted Vulnerability Information? The detail report covers detected vulnerabilities other than accepted vulnerabilities; accepted records add the decision rationale for carrying the risk. - Are the CVEs in this file real Boundera findings? No. Every finding and related technical detail is synthetic. ### FedRAMP 20x Ongoing Certification Report (OCR) Example - URL: https://boundera.io/resources/20x/fedramp-20x-ongoing-certification-report-example - Program: FedRAMP 20x - Category: Certification Data Examples - Type: example - Format: ZIP - Size: 4 KB - Updated: 2026-08-04T15:47:16.811246+00:00 - Description: See how an OCR can summarize a reporting period's changes, planned work, accepted vulnerabilities, incidents, recommendations, and feedback mechanism. - Best for: Ongoing-certification program owners; Agency customer-success teams; Report and trust-center developers - Outcomes: See how quarterly certification information can be synthesized; Connect change, vulnerability, incident, and recommendation summaries; Model a reporting period and forward planning horizon; Design human-readable and machine-readable OCR publishing - Tags: Certification Data Changes, Collaborative Continuous Monitoring, FedRAMP 20x, Ongoing Certification, Ongoing Certification Report (OCR), Quarterly Security Report, Worked Example - Included formats: HTML, JSON - Important notice: These files are synthetic FedRAMP 20x worked-example data generated on July 27, 2026. They are not an official FedRAMP template, a live production or security disclosure, evidence of Boundera's certification status, an agency authorization, or an endorsement. Check the FedRAMP Marketplace for current status, and adapt and independently validate the example before use. ## A worked quarterly narrative An Ongoing Certification Report gives necessary parties a high-level account of what changed during a reporting period and what may change next. This synthetic report covers 2026-04-28 through 2026-07-27 and illustrates how related certification information can be gathered into one reviewable summary. The pair includes fictional certification-data changes, a three-month planning horizon, accepted-vulnerability summaries, a multi-stage transformative change, updated security and configuration recommendations, a sample agency list, reportable-incident summaries, lessons learned, and a feedback channel. These sections show why an OCR is more than a vulnerability report: it connects operational change and risk information to the broader ongoing-certification picture. JSON supports structured ingestion and comparison, while HTML presents the same concepts to reviewers. ## How teams can use the example Use the report as a content-design and workflow reference. Trace each summary back to the source record that should support it: Significant Change Notifications for change history, vulnerability records for accepted-risk counts, and incident reports for incident timelines and lessons learned. A production process should define owners, source systems, reporting cutoffs, sensitivity review, factual verification, and sign-off. It should detect contradictions, such as a change marked complete in one artifact but still planned in another. The final report needs enough context for informed risk decisions while avoiding disclosure that could adversely affect the offering. Validate your report against the current Collaborative Continuous Monitoring rules and schema. ## Synthetic example and current status Every described change, vulnerability, recommendation, agency, incident, lesson, and customer impact in these **2026-07-27** files is fictional. The named agencies are not Boundera customers or authorizations, and the incident narratives are not real disclosures. Check the [official FedRAMP Marketplace record](https://www.fedramp.gov/marketplace/products/FR2628943633/) rather than treating this example as an actual Boundera OCR. #### Frequently asked questions - What reporting period does the OCR example cover? The synthetic reporting period runs from April 28 through July 27, 2026. - Is an Ongoing Certification Report only a vulnerability report? No. It brings together high-level changes, plans, accepted vulnerabilities, transformative changes, recommendations, agency use, and incident information. - Are the listed agencies and incidents real? No. They are fictional worked-example data and do not represent Boundera customers, authorizations, or production incidents. ### FedRAMP 20x Security Decision Record (SDR) Example - URL: https://boundera.io/resources/20x/fedramp-20x-security-decision-record-example - Program: FedRAMP 20x - Category: Certification Data Examples - Type: example - Format: ZIP - Size: 89 KB - Updated: 2026-08-04T15:47:16.798545+00:00 - Description: Explore a substantial SDR example containing FedRAMP rule records, KSI summaries, validation statements, evidence references, tests, and historical metrics. - Best for: Security and compliance engineers; KSI evidence owners; Assessors and technical reviewers - Outcomes: Map implementation and validation statements to rules and KSIs; Understand how KSI evidence, tests, and metrics can be represented; Compare a large JSON record with its readable HTML output; Prototype SDR search, filtering, and generation workflows - Tags: Continuous Validation, FedRAMP 20x, Historical Metrics, HTML Example, JSON Example, Key Security Indicators (KSI), Security Decision Record (SDR), Security Decisions - Included formats: HTML, JSON - Important notice: These files are synthetic FedRAMP 20x worked-example data generated on July 27, 2026. They are not an official FedRAMP template, a live production or security disclosure, evidence of Boundera's certification status, an agency authorization, or an endorsement. Check the FedRAMP Marketplace for current status, and adapt and independently validate the example before use. ## Inside the SDR example FedRAMP describes the Security Decision Record as a persistently maintained record of the security decisions made across a cloud service offering's lifecycle. This example illustrates that model through 158 synthetic FedRAMP rule records and 46 synthetic Key Security Indicator records. The rule entries demonstrate statuses, implementation statements, validation statements, and places where assessment or clarification information can be carried. The KSI entries add measures, test references, evidence descriptions, current status, and metrics. The included metrics window contains 52 example evaluation points from 2025-08-04 through 2026-07-27, plus 30-day and past-year summaries. The HTML intentionally renders a very large JSON document so teams can examine navigation, summarization, accessibility, and parity challenges. ## What to learn from the pair Use this example to study relationships, not to copy conclusions. Follow a rule identifier from its status to its implementation and validation text. Then examine a KSI from its measures and evidence through test references and historical measurements. That flow can inform data models, evidence pipelines, reviewer views, change detection, and quality checks. A useful implementation should make incomplete, stale, conflicting, or unsupported statements easy to find. It should distinguish provider verification, provider validation, independent review, and attached artifacts instead of collapsing them into a generic compliant result. Current [Security Decision Record rules](https://www.fedramp.gov/2026/providers/20x/rules/security-decision-record/) and schemas remain the source of truth for required fields and applicability. ## Synthetic example and current status These files were generated on **2026-07-27**. Their rule statuses, KSI results, evidence, metrics, people, systems, assessments, and security narratives are fictional. Some source text names a demo organization other than Boundera; that is part of the synthetic dataset, not a Boundera claim. Use the [official FedRAMP Marketplace record](https://www.fedramp.gov/marketplace/products/FR2628943633/) for current status. #### Frequently asked questions - Why is the SDR example so large? It contains 158 rule records, 46 KSI records, and 52 synthetic historical metric points for each applicable example series. - Does a Security Decision Record replace every other package artifact? No. It records security decisions and related verification, validation, assessment, and artifacts; other package materials still have distinct purposes. - Can these statuses or metrics be reused as evidence? No. They are synthetic and must not be represented as actual implementation, assessment, or certification results. ### FedRAMP 20x Certification Package Overview (CPO) Example - URL: https://boundera.io/resources/20x/fedramp-20x-certification-package-overview-example - Program: FedRAMP 20x - Category: Certification Data Examples - Type: example - Format: ZIP - Size: 7 KB - Updated: 2026-08-04T15:47:16.750167+00:00 - Description: See how a FedRAMP 20x Certification Package Overview can organize offering metadata, documentation links, service scope, contacts, and third-party resources. - Best for: Cloud service provider compliance teams; Trust-center and API engineers; Assessors and agency reviewers - Outcomes: Understand the main information groups in a Certification Package Overview; Compare machine-readable JSON with a human-readable HTML rendering; Trace service, repository, contact, and third-party resource fields; Use the pair to design content models and parity checks - Tags: Certification Package, Certification Package Overview (CPO), Cloud Service Offering, FedRAMP 20x, Human-Readable HTML, Machine-Readable JSON, Worked Example - Included formats: HTML, JSON - Important notice: These files are synthetic FedRAMP 20x worked-example data generated on July 27, 2026. They are not an official FedRAMP template, a live production or security disclosure, evidence of Boundera's certification status, an agency authorization, or an endorsement. Check the FedRAMP Marketplace for current status, and adapt and independently validate the example before use. ## What this CPO pair demonstrates A Certification Package Overview gives readers a concise, high-level view of a cloud service offering and the information available in its FedRAMP Certification Package. This worked pair shows one possible way to represent that overview in both machine-readable JSON and human-readable HTML. The example groups package metadata, service identification, service and deployment properties, contact information, documentation repositories, a service list, and third-party information resources. It also demonstrates how a public overview can point readers toward a trust center, secure configuration guidance, policies, inventories, information flows, and supporting materials without placing every detail in one document. The JSON supports APIs, validation, indexing, and automated comparison; the HTML gives reviewers a readable presentation of the same conceptual record. ## How to use the example Begin with the HTML to understand the intended reading experience, then locate the corresponding values and nested objects in the JSON. This makes the pair useful when designing a trust-center data model, testing human and machine-readable parity, or planning a CPO generation workflow. Treat the structure as a learning aid, not as a drop-in certification package. Review the current FedRAMP schema and rules, determine which fields apply to your offering and Certification Profile, and replace every sample contact, service, repository, scope, and third-party resource with verified information. A CPO is not proof that the underlying implementation, validation, assessment, or supporting artifacts are complete. See the current [FedRAMP guidance for 20x certification packages](https://www.fedramp.gov/2026/agencies/use/packages/20x/). ## Synthetic example and current status These files were generated on **2026-07-27** as synthetic worked examples. They do not describe live Boundera production architecture, controls, customers, agency use, assessment results, authorization, or certification facts. Do not infer Boundera's status from the example; consult the [official FedRAMP Marketplace record](https://www.fedramp.gov/marketplace/products/FR2628943633/) for current information. #### Frequently asked questions - What is included in the CPO download? A JSON example and a corresponding human-readable HTML rendering of a synthetic Certification Package Overview. - Is this an official FedRAMP template? No. It is a worked example aligned to the artifact's concepts. Review the current official rules and schema before using the structure. - Does this show that Boundera is FedRAMP certified? No. The files contain synthetic data. Current status is available from the linked FedRAMP Marketplace record. ### Sample Security Policy Library (20+ Policies) - URL: https://boundera.io/resources/rev5/security-policy-library - Program: FedRAMP Rev 5 - Category: Policy Examples - Type: template - Format: ZIP - Updated: 2026-06-22T07:26:15.455917+00:00 - Description: Collection of 20+ required security policies and procedures for FedRAMP. Includes Access Control, Incident Response, Change Management, and more. - Best for: Teams standing up a policy set; Consultants packaging policies for clients - Outcomes: Policy drafting accelerator; Consistent language across your document set; Faster review with legal and security stakeholders - Tags: FedRAMP, Templates ### FedRAMP Readiness Assessment Checklist - URL: https://boundera.io/resources/rev5/fedramp-readiness-checklist - Program: FedRAMP 20x and Rev 5 - Category: Checklists - Type: checklist - Format: PDF - Updated: 2026-06-22T07:26:15.453939+00:00 - Description: Self-assessment checklist to determine if your organization is ready to begin FedRAMP authorization. Covers technical, operational, and business readiness. - Best for: Early-stage readiness work; Executive planning - Outcomes: Quick readiness scoring; Gap visibility before full authorization spend; Better stakeholder alignment - Tags: Checklist, FedRAMP ### FedRAMP Low Baseline System Security Plan (SSP) - URL: https://boundera.io/resources/rev5/fedramp-low-baseline-ssp - Program: FedRAMP Rev 5 - Category: Templates - Type: template - Format: DOCX - Size: 215 KB - Updated: 2026-06-22T07:26:15.450038+00:00 - Description: SSP template for FedRAMP Low baseline with 125 security controls. Ideal for systems processing publicly releasable information. - Best for: Low-impact systems; Teams validating a lighter authorization path - Outcomes: Low-baseline SSP starter; Clearer scope for lightweight systems; Reusable control narrative format - Tags: FedRAMP, Low, SSP, Templates ### FedRAMP LI-SaaS Baseline System Security Plan - URL: https://boundera.io/resources/rev5/fedramp-li-saas-baseline-ssp - Program: FedRAMP Rev 5 - Category: Templates - Type: template - Format: DOCX - Size: 215 KB - Updated: 2026-06-22T07:26:15.448004+00:00 - Description: Tailored SSP template for Low Impact SaaS applications. Streamlined baseline for simple SaaS products. - Best for: Simple SaaS offerings; Teams exploring LI-SaaS eligibility - Outcomes: Tailored LI-SaaS starting point; Simpler baseline coverage; Faster internal review for narrow-use SaaS - Tags: FedRAMP, Low, SSP, Templates ### FedRAMP Budget & Timeline Calculator - URL: https://boundera.io/resources/rev5/fedramp-budget-timeline-calculator - Program: FedRAMP 20x and Rev 5 - Category: Planning Tools - Type: tool - Format: XLSX - Updated: 2026-06-22T07:26:15.440713+00:00 - Description: Interactive spreadsheet to estimate FedRAMP authorization costs and timeline based on your baseline level and current readiness. - Best for: Finance planning; Founders; Program planning - Outcomes: Budget range planning; Timeline forecast by readiness profile; Stronger executive case for investment - Tags: FedRAMP ### Evidence Collection Guide by Control Family - URL: https://boundera.io/resources/20x/evidence-collection-guide - Program: FedRAMP 20x - Category: Guides & Playbooks - Type: guide - Format: PDF - Updated: 2026-06-22T07:26:15.436354+00:00 - Description: Comprehensive guide showing what evidence is needed for each NIST 800-53 control family. Includes automated evidence sources. - Best for: Evidence owners; Security engineers; Assessment prep - Outcomes: Cleaner evidence planning; Less screenshot churn; Better preparation for assessments and reviews - Tags: FedRAMP ### Control Implementation Matrix Template - URL: https://boundera.io/resources/20x/control-implementation-matrix - Program: FedRAMP 20x - Category: Planning Tools - Type: tool - Format: XLSX - Updated: 2026-06-22T07:26:15.430980+00:00 - Description: Excel-based matrix for tracking implementation status of all NIST 800-53 controls. Includes responsibility assignments and evidence links. - Best for: Security PMs; Control owners; Consulting teams - Outcomes: Control-to-owner mapping; Evidence traceability in one place; Fewer coordination gaps during remediation - Tags: FedRAMP, Templates ## Machine-Readable Links - Sitemap: https://boundera.io/sitemap.xml - Robots: https://boundera.io/robots.txt - Author graph: https://boundera.io/author.json - Concise LLM context: https://boundera.io/llms.txt - Full LLM context: https://boundera.io/llms-full.txt