Official source: Significant Change Notification (
SCN), FedRAMP Consolidated Rules release 2026.10.14.01. This page is a plain-English summary. The official rule text governs.In short
You can make significant changes to your own service without asking FedRAMP for approval in advance. In return, you must classify each change and tell agency customers about it on a fixed timeline. Routine recurring changes, such as normal patching, need no notification. Adaptive changes need a notice within 10 business days after you finish. Transformative changes need notices before you start (30 and 10 business days ahead), after you finish and after verification. A change of FedRAMP Certification class can’t go through SCN at all: it requires a new assessment.Who it applies to
The subsets list Classes B, C and D. No SCN rule has a class-specific variant, and no SCN rule appears on the Class A mandatory or recommended lists in
FRC-CLA-MFR or FRC-CLA-RFR.Key dates
How to classify a change
SCN-CSO-EVA requires you to evaluate every potential significant change in this order:
1
Is it a significant change?
If yes, keep evaluating and follow the SCN rules.
2
Is it a FedRAMP Certification class change?
If yes, it requires a new assessment and can’t be done under the SCN rules.
3
Is it a routine recurring change?
If yes, follow the Routine Recurring Changes rules (
SCN-RTR).4
Is it a transformative change?
If yes, follow the Transformative Changes rules (
SCN-TRF).5
Otherwise, it is an adaptive change
Follow the Adaptive Changes rules (
SCN-ADP).Notification timeline
These timeframes are the same for every class.
Upstream marks each notification as an update to FedRAMP Certification Data for all necessary parties.
What you need to do
General provider responsibilities
Required information for every notification (
SCN-CSO-INF):
- Service Offering FedRAMP ID
- Assessor name (if applicable)
- Related vulnerability (if applicable)
- Significant change type and explanation of categorization
- Short description of the change
- Reason for the change
- Summary of customer impact, including changes to services and customer configuration responsibilities
- Plan and timeline, including for verification, assessment and/or validation of impacted Key Security Indicators or Rev5 controls
- Copy of the business or security impact analysis
- Name and title of the approver
Routine recurring changes
Upstream’s key tests for routine recurring changes include routine care by staff during normal duties, no major impact to availability, no executive approval, minor incremental patching and no breaking changes. Its examples include scaling capacity, tuning performance, updating firewall rules, refreshing tokens, updating signatures, routine patching and like-for-like replacement of a known-bad component. If an activity doesn’t occur regularly and routinely, it can’t be this type. Replacing all physical firewalls to fix a vulnerability is the upstream counterexample.
Adaptive changes
Upstream says most changes that don’t happen regularly will be adaptive. Key tests: minimal changes to security plans or procedures, some careful planning (less than a transformative change needs), and verification of existing functionality and secure configuration afterward. Examples include updates with known breaking changes or service disruption, larger multi-week feature work, swapping a cryptographic module for one meeting the same standards, like-for-like component replacements that need some procedure changes, and adding models to existing approved AI services without exposing federal customer data to new services.
Transformative changes
Upstream says transformative changes are rare. Small offerings may go years without one, while hyperscale providers may have several a year. Key tests: the change alters the service’s risk profile or customer responsibilities, needs significant new design and project planning, or requires extensive updates to assessments and documentation. Examples include adding, removing or replacing a critical third-party service (such as an IaaS change), raising the security categorization of a service that handles federal customer data, moving to containers or Kubernetes, a datacenter migration that moves federal customer data across unusual boundaries, and a new AI capability that uses federal customer data in a new way.
FedRAMP responsibilities
What FedRAMP staff have said
Adopting new FedRAMP rules is a significant change. Adopting rules that change your existing processes will “almost certainly” count as a significant change, so follow the SCN rules and notify your customers. nicole-gov, 2026-07-24, discussion #147
The VDR/VER transition is usually adaptive. Moving to VDR/VER should be treated as a significant change whether you follow SCR or SCN. Staff expect most of these transitions to be adaptive, but it depends on what you need to change. If the transition is transformative, independent validation is only required where human validation is needed. paulagosta, 2026-08-26, discussion #146
Follow the rule, not the schema. The SCN JSON schema marks fewer fields as required than
SCN-CSO-INF. Staff said the schemas are deliberately minimal and are “a sort of skeleton.” Follow the written rules, not templates or schemas. pete-gov, 2026-06-27, discussion #146. The schema’s certificationPackageOverviewUri field points to your Certification Package Overview, so you don’t repeat offering metadata in every submission. dan-fedramp, 2026-06-30Related
- Vulnerability detection and response
- Certification data sharing: where notifications live as Certification Data
- Certification package overview
- Collaborative continuous monitoring: transformative changes in the Ongoing Certification Report
- FedRAMP certification: changing certification class
- Rev5 questions on the 2026 rules