FedRAMP Moderate Baseline: Controls, Evidence, and Effort

The FedRAMP Moderate baseline is not a 323 item spreadsheet exercise. It is a current Class C operating commitment for the real cloud service, the real boundary, and the evidence that proves both.

The count matters, but it is not the plan. A provider can have hundreds of rows marked implemented and still fail review because the asset inventory trails production, customer duties are vague, inherited controls are assumed, validation samples do not match the boundary, or evidence describes last quarter.

The working standard is stricter: define the service, assign every control, connect each claim to a mechanism and artifact, test the deployed result, close material findings, and keep the record current after certification.

The FedRAMP Compliance hub connects this guide to the broader authorization program. Use the complete FedRAMP compliance guide for route and package context, the FedRAMP continuous monitoring guide for the operating cycle, and the secure cloud architecture guide to shape the boundary. GS Consulting supports the same work through secure AI automation.

FedRAMP Moderate Baseline: The Short Answer

FedRAMP described the 2023 Rev5 Moderate baseline as 323 controls. The 2026 transition notice maps current Moderate services to Rev5 Class C. GS counted 322 controls and enhancements across eighteen families in the current published Class C list.

That one item difference does not mean the work became easier. The lists come from different publication contexts. Current rules also change the record, assessment, vulnerability, change, data sharing, and ongoing review around the baseline. Use the exact list and transition path that govern the service.

A useful baseline plan has four layers. First, the service boundary and impact class. Second, control ownership and implementation. Third, validation and independent assessment. Fourth, the recurring evidence needed to maintain certification. If the plan stops at layer two, it is incomplete.

The 2026 Transition Changes the Package

FedRAMP launched its Consolidated Rules for 2026 on June 24, 2026. Optional adoption began July 4, 2026. Many rules set January 1, 2027 as an obtain or maintain date, with rule specific grace periods. FedRAMP also says new legacy Rev5 certifications stop after June 11, 2027, while existing Rev5 authorizations remain active through at least December 31, 2028.

Those dates do not produce one universal deadline for every provider. A current authorization, an active package, a new certification, and an agency agreement can sit on different tracks. Record which rule version applies, what the sponsor expects, which materials are accepted during transition, and when the next assessment starts.

The most visible documentation change is the Security Decision Record. It is designed to replace the traditional system security plan record over the transition. For each control, the record captures organization defined parameters, implementation status, mechanism or activity, verification, validation, independent verification and validation, comments, and artifact references.

Do not rename an old document and call the transition complete. The operating model changes when each control row must connect a decision, actual implementation, verification method, validation result, independent review, and current evidence.

What the Class C Baseline Contains

The current Class C list spans eighteen control families. Access Control is largest at forty three controls and enhancements. System and Communications Protection has twenty nine. Configuration Management and Identification and Authentication each have twenty seven. System and Information Integrity has twenty four. Contingency Planning has twenty three.

Counts show surface area. They do not show difficulty by themselves. One inherited control can still require provider proof and customer terms. One small family can carry material operational consequences. Use counts to check completeness, then use the real boundary and implementation to estimate work.

GS Class C Control Coordination Index

GS Consulting built a derived planning model across all eighteen current Class C families. Two public inputs come from the official FedRAMP lists: the total controls and enhancements in each family and the controls and enhancements in the published annual independent assessment subset. Four one to five analyst ratings capture implementation reach, evidence variety, shared responsibility, and change sensitivity.

The base model weights total baseline count at 30 percent, annual assessment count at 20 percent, implementation reach at 20 percent, evidence variety at 15 percent, shared responsibility at 10 percent, and change sensitivity at 5 percent. Counts are normalized against the family maximums of forty three and sixteen. The sensitivity case shifts five points from total count to the annual subset.

Access Control scores 100.0. System and Communications Protection scores 87.7. Configuration Management scores 78.8, System and Information Integrity scores 78.0, and Identification and Authentication scores 77.1. These families combine a large formal surface with broad implementation and recurring evidence across the service.

The alternate weights preserve the top five order. No score moves by more than 2.4 points. That stability supports one practical sequence: settle access and protection architecture first, then configuration, integrity, and identity, while building the remaining families into the same evidence system.

This is a GS Consulting derived planning tool, not a FedRAMP score, risk rating, audit result, legal opinion, or certification decision. It estimates coordination pressure. The source register, public observations, assumptions, formulas, sensitivity results, workbook, CSV files, and editable SVGs are preserved in the research package.

Start with the Boundary and Control Ownership

The boundary record should name the cloud service, components, data types, federal use, regions, external services, administration paths, support systems, customer connections, corporate services, and explicit exclusions. Diagrams need trust zones, data flows, interfaces, protection points, and responsibility boundaries. Inventory and diagrams must describe the same system.

Then assign every control. Use four ownership states: provider, customer, inherited, and shared. Each row needs an accountable implementation owner and an evidence owner. Shared does not mean unclear. It means the provider and customer duties are separately named, contractually visible where appropriate, and testable.

Inherited controls need proof of inheritance. Name the provider or service, the assurance source, the exact capability inherited, the configuration conditions, the remaining provider duty, the customer duty, and what happens if the inherited service changes. A marketplace listing alone is not a control implementation.

Keep the FedRAMP, CMMC, and NIST 800-171 comparison close when contract teams mix regimes. Similar control language does not make evidence packages interchangeable. The scope, assessor, authorization decision, customer, and ongoing duties differ.

Build the Security Decision Record as an Operating Index

A useful Security Decision Record answers seven questions for every control. What parameter did the organization choose? What mechanism or activity implements the control? Where does it operate? Who owns it? How was it verified? What did validation show? Which artifact lets a reviewer reproduce that conclusion?

Artifact references should be specific. A folder path is not enough. Record the artifact name, source system, evidence period, control relationship, owner, approver, retention rule, sensitivity, and access method. If the artifact changes every month, identify the repeatable query or export that creates it.

Separate design evidence from operating evidence. A policy, architecture decision, and configured rule can explain the intended mechanism. A ticket, log, report, test, approval, or review result shows that the mechanism operated. Strong control proof normally needs both.

Do not hide incomplete work behind implementation status. Record the actual state, gap, compensating action if accepted, owner, due date, dependency, and test needed for closure. Reviewers can work with a controlled problem. They cannot rely on an optimistic label.

Plan for Independent Assessment Before the Package Is Finished

The current Class C independent verification and validation rules require an assessment at least annually. GS counted eighty controls and enhancements in the published annual subset. Access Control has sixteen, System and Communications Protection has fourteen, Audit and Accountability has eleven, and Identification and Authentication and System and Information Integrity each have nine.

Initial certification also has freshness rules. Current Class C certification materials must have been verified and validated within the previous seven days, and the fresh independent assessment must have been completed within the previous three months. These are not arguments for rushing. They are reasons to design repeatable collection and review before the final window.

Bring the assessor into boundary, sample, evidence, access, and schedule discussions while design can still change. Ask which systems must be reachable, what read access is needed, how customer duties will be tested, which inherited claims need independent support, how samples will be selected, and how failed procedures will be tracked.

Assessment readiness is not a document count. It is the ability to reproduce a conclusion from the current service. A reviewer should be able to move from control, to implementation, to resource, to evidence, to test, to result, without asking the provider to invent the trail during fieldwork.

Estimate Effort by Dependency and Repetition

There is no credible universal timeline or price for FedRAMP Moderate. Effort expands with boundary breadth, service change, custom infrastructure, weak inventory, manual evidence, customer configuration, unclear inheritance, provider access limits, open vulnerabilities, and late assessment findings.

Estimate the work in five separate ledgers:

• Architecture work: boundary, data flow, isolation, identity, logging, resilience, cryptography, external services, and administrative access.
• Control work: parameters, implementation, ownership, procedures, configuration, customer duties, and inherited conditions.
• Evidence work: queries, exports, screenshots where justified, tickets, approvals, tests, reconciliation, retention, and reviewer access.
• Assessment work: planning, samples, interviews, demonstrations, requests, findings, responses, validation, and closure.
• Operating work: vulnerabilities, changes, incidents, availability, reporting, quarterly review, annual assessment, and history.

For each ledger, estimate initial build and recurring operation separately. The first dashboard export may take a day to design. A reliable monthly export may take minutes after automation. A cheap initial package can create expensive monthly labor if the underlying data never reconciles.

Failure Modes That Create Expensive Rework

Counting without ownership. Teams turn the control total into a project list but never map dependencies, customer duties, or evidence. Work looks complete until review crosses systems.

Freezing the wrong boundary. A diagram excludes a support path, shared platform, region, external service, or administrator route that production depends on. Every downstream control and sample becomes questionable.

Using template evidence. Generic policies explain intent but do not prove the deployed mechanism, period, resource, owner, or result. The package grows while assurance stays thin.

Assuming shared responsibility. Provider documentation uses broad customer language. The customer cannot tell what to configure or retain, and the assessor cannot tell which side owns the test.

Waiting to involve the assessor. Samples, access, evidence format, and testability problems surface after architecture and schedule are fixed.

Treating authorization as the finish line. The service changes, findings age, evidence goes stale, and the next reporting cycle becomes a reconstruction exercise.

A Ninety Day Class C Preparation Plan

Days one through fifteen: set the governing path. Confirm the certification class, current rule set, transition dates, sponsor expectations, assessment agreement, service owner, decision rights, and risk escalation. Freeze a versioned boundary draft and resolve obvious exclusions.

Days sixteen through thirty: assign the baseline. Load the governing control list, record organization defined parameters, assign provider, customer, inherited, and shared duties, name implementation and evidence owners, and identify dependencies across families.

Days thirty one through fifty: build the evidence index. Link each control to mechanisms, resources, artifacts, queries, tests, periods, owners, reviewers, and retention. Mark gaps honestly. Prioritize access, communications protection, configuration, integrity, and identity dependencies.

Days fifty one through seventy: test the service. Run representative validation, compare inventory to architecture and scanners, test customer duties, verify inherited conditions, repair evidence access, and open controlled findings for material gaps.

Days seventy one through ninety: rehearse review. Give an independent reviewer the current record and require them to reproduce conclusions. Resolve questions, close serious findings, establish the recurring monitoring calendar, and keep the package fresh enough for the actual certification window.

The Minimum Class C Evidence Packet

The packet needs eight connected records: boundary record, control ownership map, Security Decision Record, architecture proof, evidence register, assessment record, change history, and ongoing certification record. Each record should have an owner, version, period, approval, retention rule, and relationship to the service.

The connection is the point. A change should update architecture if needed, trigger control review, create test evidence, enter the change history, and flow into ongoing reporting. A vulnerability should resolve to an asset, boundary, control, decision, owner, due date, evidence, and closure result.

Bottom Line

FedRAMP Moderate is still a useful market term. It is not enough to run the program. Current work needs a named Rev5 Class C path, a precise service boundary, explicit ownership, a live Security Decision Record, repeatable evidence, independent assessment, and Ongoing Certification.

The decisive operating standard is simple: make every control claim traceable to the current service, a named owner, a tested mechanism, a dated artifact, and a maintained decision.

Sources and Method Note

• FedRAMP Consolidated Rules for 2026 Notice
• FedRAMP Rev5 Class C Certification Rules
• FedRAMP Class C Independent Verification and Validation
• FedRAMP Class C Security Decision Record
• FedRAMP 2026 Provider Transition Guidance
• FedRAMP Revision 5 Transition Overview

GS Consulting Original Research. The GS Class C Control Coordination Index is a derived planning tool based on cited public sources and documented analyst assumptions. It is not a FedRAMP score, legal opinion, official control interpretation, assessment result, authorization, certification decision, or compliance determination. Verify obligations, dates, and evidence requirements against current FedRAMP rules, agency direction, and the applicable agreement.

Frequently Asked Questions

Related Reading

• FedRAMP Compliance Hub
• FedRAMP Compliance Guide
• FedRAMP Continuous Monitoring Guide
• FedRAMP, CMMC, and NIST 800-171 Comparison
• Secure Cloud Architecture for Federal Contractors
• Secure AI Automation