What Counts as a Significant Change Under FedRAMP, and When Must I Report It to the Agency?

Your team plans a big platform change next quarter. Your authorization covers the system as it stands today. The question is whether that change needs agency approval first.

FedRAMP means Federal Risk and Authorization Management Program. A significant change is a change that could affect the security state of an authorized service. The agency that granted the authorization decides what counts. You do not decide alone. You raise the change early and let the agency judge it.

What counts as significant

A change is likely significant if it alters the security posture. Moving to a new data center counts. Changing the system architecture counts. Adding a new external service counts. Changing the types of federal data you hold counts. Changing the authorization boundary counts. A boundary is the line around what the authorization covers.

Routine changes do not count. Patching a server to the same version does not count. Replacing a failed disk does not count. Small config fixes that match the approved design do not count. When in doubt, treat the change as significant and ask. Asking early costs little. Building first and asking later costs a lot.

When to report it

Report a significant change before you build it. FedRAMP continuous monitoring guidance sets this order. First, you prepare a security impact analysis. That analysis states what changes and what risks it brings. Second, you discuss it with the authorizing official. AO means authorizing official. Third, you submit a Significant Change Request form and a Security Assessment Plan. SAP means Security Assessment Plan. The agency must approve these before you implement the change.

After you build the approved change, the work is not done. A Third-Party Assessment Organization tests the change. 3PAO means Third-Party Assessment Organization. You then submit a new Security Assessment Report and updated package documents. SAR means Security Assessment Report. The updated System Security Plan is part of that package. SSP means System Security Plan. The agency reviews the results before the change is treated as fully authorized.

What to put in the request

The request needs five facts. First, a plain description of the change. Second, the parts of the system it touches. Third, the security impact analysis. Fourth, the test plan for the change. Fifth, the schedule for building and testing it. Attach the updated drawings for the affected parts. Name the controls that change. Name the controls that stay the same. An agency reviewer should judge the risk from your request alone.

What happens if you skip the step

An unreported significant change breaks trust in the authorization. The agency may treat the system as out of compliance. It may ask for a fresh assessment of the whole change. It may pause reliance on the authorization until the review closes. None of these outcomes is worth the time saved by skipping the request. Build the request into your change plan from the start.

This article explains FedRAMP in general terms. It does not claim any authorization for PolicyCortex. PolicyCortex is a commercial compliance platform. It is not FedRAMP authorized. Check the current FedRAMP process with your authorizing agency, since FedRAMP updates its process over time.

Sources

• FedRAMP Agency Guide for Multi-Agency Continuous Monitoring.
• NIST SP 800-37 Revision 2, Risk Management Framework.
• Original diagram by PolicyCortex.

Next step

Want evidence tied to each control from live systems? See how PolicyCortex collects it.