No formal notice
Routine work by staff during normal duties, with no major availability impact and no executive approval. FedRAMP says providers should not send formal notices for these (SCN-RTR-NNR).
Key takeaway: Under CR26, providers notify necessary parties of a significant change instead of asking for approval first. FedRAMP does not require agency approval of a change, and each notice names the provider's own internal approver. What a provider owes depends on the type of change: routine recurring changes need no notice, adaptive changes are notified within 10 business days after they finish, and transformative changes are announced at least 30 business days before they start. The ruleset applies to Rev5 providers from January 1, 2027, with a grace period to June 1, 2027.
See What Is FedRAMP 20x, the 20x roadmap, OSCAL for FedRAMP and NISTcompliance.ai for the tooling that keeps notices and evidence in one record.
Rule IDs SCN-ADP-NTF, SCN-TRF-NIP, SCN-TRF-NAF and SCN-CSO-HIS. Dates checked against fedramp.gov on October 14, 2026.
Under Rev5, providers submitted a Significant Change Request and waited for approval. CR26 replaces that gate with a notice.
| Factor | Legacy Significant Change Request | CR26 Significant Change Notification |
|---|---|---|
| Operating model | Prior approval. Providers requested and waited. | Notification. Providers notify and record their own approver. |
| Who decides | The authorizing official approved or rejected the request. | The provider decides and notifies. FedRAMP may require delays or advance approval only under a Corrective Action Plan (SCN-FRP-CAP). |
| Timing | The change waited on the approval. | By change type, from no notice at all to 30 business days of advance notice. |
| Format | Standalone request documents. | Notices in human-readable and JSON formats (SCN-CSO-HRM), recorded in FedRAMP Certification Data. |
| Assessor | Reviewed the request before the change. | Third-party assessor review should be engaged before a transformative change when human validation is needed (SCN-TRF-TPR). |
The notification threshold is the same idea as the old request threshold. What changes is the gate: providers no longer wait for approval, and the notice carries the evidence that the posture is maintained.
Primary sources SCN rules, 20x, SCN rules, Rev5.
The type of change sets the notice a provider owes. Examples below are the ones FedRAMP gives.
Routine work by staff during normal duties, with no major availability impact and no executive approval. FedRAMP says providers should not send formal notices for these (SCN-RTR-NNR).
Minimal changes to security plans or procedures, with some planning and verification of functionality and secure configuration afterward.
Changes the service risk profile or customer responsibilities, needs significant new design and testing, or needs extensive updates to assessments and documentation.
During an emergency or incident a provider may make significant changes without following the SCN rules in advance. It must still follow its procedures, notify necessary parties, provide SCN materials afterward and complete an assessment (SCN-CSO-EMG).
Providers evaluate every potential change in order: is it a significant change, does it change the certification class, is it routine recurring, is it transformative, and otherwise it is adaptive. A change of certification class needs a new assessment, not a notice (SCN-CSO-EVA).
Business days are counted by the provider. The rules for adaptive and transformative changes are the same for 20x and Rev5.
| Rule | When | What to send |
|---|---|---|
| SCN-ADP-NTFAdaptive | Within 10 business days after finishing | Notice to all necessary parties, with a summary of new risks or vulnerabilities if applicable. |
| SCN-TRF-NIPTransformative | At least 30 business days before starting | Initial plans, with likely security impacts. |
| SCN-TRF-NFPTransformative | At least 10 business days before starting | Final plans, with updates to earlier information. |
| SCN-TRF-NAFTransformative | Within 5 business days after finishing | Notice that the change is finished. |
| SCN-TRF-NAVTransformative | Within 5 business days after verification, assessment or validation | The updated information, a risk summary, and the security assessment report if applicable. |
| SCN-TRF-UPDTransformative | Within 30 business days after finishing | Updated service documentation. This does not require updating the SSP or the certification package. |
| SCN-CSO-EMGEmergency | During the emergency or incident | Notify necessary parties and provide SCN materials retroactively, then complete an assessment. |
For 20x certifications it applies from July 4, 2026 to obtain certification and from January 1, 2027 to maintain it, and the grace period ends at the first independent assessment started after January 1, 2027. For Rev5 certifications it applies from January 1, 2027, with a grace period to June 1, 2027. A provider must adopt the ruleset by its grace date or FedRAMP Certification will be revoked.
Cybertorch generates validation evidence as a by-product of SOC operations. NISTcompliance.ai organizes that evidence into the notice, the SSP update and the POA&M.
Inherited controls stay inside Cybertorch's boundary, so your own change evaluation centers on the components you own and configure. Your inheritance responsibilities are confirmed in your Cybertorch responsibility matrix.
Cybertorch's continuous monitoring supplies the verification evidence a notice points to, so the notice and the evidence come from the same operating record.
In the NISTcompliance.ai continuous monitoring platform, the SSP and POA&M stay current and the affected controls, evidence and impact analysis are organized so the notice record is complete.
The same change updates CMMC Level 2 and FISMA documentation alongside FedRAMP, from one evidence base.
Modernize your change management and continuous monitoring with Quzara advisory, Cybertorch monitoring and NISTcompliance.ai automation. Engage Quzara through our GSA HACS vehicle or directly.