KSI-AFR-SCN—Significant Change Notifications
Formerly KSI-AFR-05
>Control Description
>NIST 800-53 Controls
>FRMR Requirements21
Normative requirements from the FedRAMP Requirements and Recommendations document — 13 mandatory, 3 recommended, 5 optional.
Evaluate Changes
Providers MUST evaluate all potential significant changes to determine the type of significant change and apply the appropriate Significant Change Notification requirements and recommendations.
- Is it a significant change? --> Continue evaluation and follow the Significant Change Notification process.
- If it is, is it an impact categorization change? --> This requires a new assessment and cannot be done under the Significant Change Notification process.
- If it is not, is it a routine recurring change? --> Follow the Routine Recurring Change process (SCN-CSO-RTR).
- If it is not, is it a transformative change? --> Follow the Transformative Change process (SCN-CSO-TRF).
- If it is not, then it is an adaptive change --> Follow the Adaptive Change process (SCN-CSO-ADP).
Maintain Audit Records
Providers MUST maintain auditable records of significant change evaluation activities and make them available to all necessary parties.
Required Information
Providers MUST include at least the following information in Significant Change Notifications:
- Service Offering FedRAMP ID
- Assessor Name (if applicable)
- Related POA&M (if applicable)
- Significant Change type and explanation of categorization
- Short description of change
- Reason for change
- Summary of customer impact, including changes to services and customer configuration responsibilities
- Plan and timeline for the change, including for the verification, assessment, and/or validation of impacted Key Security Indicators or controls
- Copy of the business or security impact analysis
- Name and title of approver
Historical Notifications
Providers MUST keep historical Significant Change Notifications available to all necessary parties at least until the service completes its next annual assessment.
Human and Machine-Readable
Providers MUST make ALL Significant Change Notifications and related audit records available in similar human-readable and compatible machine-readable formats.
Notification Requirements
Providers MUST notify all necessary parties within 10 business days after finishing adaptive changes, also including the following information:
- Summary of any new risks identified and/or POA&Ms resulting from the change (if applicable)
Activities that match the adaptive significant change type are a frequent and normal part of iteratively improving a service by deploying new functionality or modifying existing functionality in a way that is typically transparent to customers and does not introduce significant new security risks.
In general, most changes that do not happen regularly will be adaptive changes. This change type deliberately covers a wide range of activities in a way that requires assessment and consideration.
Option to Opt Out
Providers MUST allow agency customers to OPT OUT of transformative changes whenever feasible.
Notification of Initial Plans
Providers MUST notify all necessary parties of initial plans for transformative changes at least 30 business days before starting transformative changes.
Notification of Final Plans
Providers MUST notify all necessary parties of final plans for transformative changes at least 10 business days before starting transformative changes.
Notification After Finishing
Providers MUST notify all necessary parties within 5 business days after finishing transformative changes, also including the following information:
- Updates to all previously sent information
Notification After Verification
Providers MUST notify all necessary parties within 5 business days after completing the verification, assessment, and/or validation of transformative changes, also including the following information:
- Updates to all previously sent information
- Summary of any new risks identified and/or POA&Ms resulting from the change (if applicable)
- Copy of the security assessment report (if applicable)
Update Documentation
Providers MUST publish updated service documentation and other materials to reflect transformative changes within 30 business days after finishing transformative changes.
Implementation Summaries
Providers MUST maintain simple high-level summaries of at least the following for each Key Security Indicator:
- Goals for how it will be implemented and validated, including clear pass/fail criteria and traceability
- The consolidated _information resources_ that will be validated (this should include consolidated summaries such as "all employees with privileged access that are members of the Admin group")
- The machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- The non-machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- Current implementation status
- Any clarifications or responses to the assessment summary
No Notification Requirements
Providers SHOULD NOT make formal Significant Change Notifications for routine recurring changes; this type of change is exempted from the notification requirements of this process.
Activities that match the routine recurring significant change type are performed regularly and routinely by cloud service providers to address flaws or vulnerabilities, address incidents, and generally perform the typical maintenance and service delivery changes expected during day-to-day operations.
These changes leverage mature processes and capabilities to identify, mitigate, and remediate risks as part of the change. They are often entirely automated and may occur without human intervention, even though they have an impact on security of the service.
If the activity does not occur regularly and routinely then it cannot be a significant change of this type (e.g., replacing all physical firewalls to remediate a vulnerability is obviously not regular or routine).
Third-Party Review
Providers SHOULD engage a third-party assessor to review the scope and impact of the planned change before starting transformative changes if human validation is necessary; such reviews SHOULD be limited to security decisions that require human validation.
Application within MAS
Providers SHOULD apply ALL Key Security Indicators to ALL aspects of their cloud service offering that are within the FedRAMP Minimum Assessment Scope.
5 optional guidance (MAY)
Corrective Action Plan Conditions
FedRAMP MAY require providers to delay significant changes beyond the standard Significant Change Notification period and/or submit significant changes for approval in advance as a condition of a formal FedRAMP Corrective Action Plan or other agreement.
Additional Relevant Information
Providers MAY include additional relevant information in Significant Change Notifications.
Notification Mechanisms
Providers MAY notify necessary parties in a variety of ways as long as the mechanism for notification is clearly documented and easily accessible.
Emergency Changes
Providers MAY execute significant changes (including transformative changes) during an emergency or incident without meeting Significant Change Notification requirements in advance ONLY if absolutely necessary. In such emergencies, providers MUST follow all relevant procedures, notify all necessary parties, retroactively provide all Significant Change Notification materials, and complete appropriate assessment after the incident.
AFR Order of Criticality
Providers MAY use the following order of criticality for approaching Authorization by FedRAMP Key Security Indicators for an initial authorization package:
- Minimum Assessment Scope (MAS)
- Authorization Data Sharing (ADS)
- Using Cryptographic Modules (UCM)
- Vulnerability Detection and Response (VDR)
- Significant Change Notifications (SCN)
- Persistent Validation and Assessment (PVA)
- Secure Configuration Guide (RSC)
- Collaborative Continuous Monitoring (CCM)
- FedRAMP Security Inbox (FSI)
- Incident Communications Procedures (ICP)
>Trust Center Components3
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express significant changes through automated notification pipelines — IaC change detection triggering impact assessments, webhook-driven agency notifications with structured payloads, and an immutable change log showing every notification sent. The change log becomes an auditable artifact generated by the pipeline, not a manually maintained spreadsheet.
Change Communication Log
Immutable log of significant change notifications sent to agencies — generated by automated pipelines with timestamps and impact assessments
Change Impact Assessment Process
How significant changes are assessed for security impact before notification — including automated detection of boundary-affecting changes
Change Notification Policy
Human-readable policy for how agencies are notified of significant changes — the intent behind automated notification workflows
>Programmatic Queries
CLI Commands
gh api repos/{owner}/{repo}/releases --jq '.[].{tag: .tag_name, name: .name, published: .published_at, body: .body[:100]}' | head -10gh pr list --label security --state all --json number,title,mergedAt --limit 20>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Does your significant change definition cover all change types — architectural changes, new integrations, provider migrations, major version upgrades, and personnel changes in key security roles?
- •How do you ensure changes made by third-party providers or inherited service layers are evaluated against your SCN criteria?
- •Are there categories of changes your team considers routine that FedRAMP might classify as significant, and how do you reconcile that gap?
- •When multiple smaller changes compound into a significant change, how is that cumulative impact captured?
Automation & Validation:
- •What automated rules in your CI/CD or change management system flag changes that meet the significant change threshold?
- •What happens if a significant change is deployed without triggering the notification workflow — how do you detect and remediate that miss?
- •How do you automatically assess the security impact of a change before determining if notification is required?
- •What test evidence confirms your change detection thresholds correctly identify all changes requiring FedRAMP notification?
Inventory & Integration:
- •How does your change management system (Jira, ServiceNow, GitHub) integrate with your SCN notification workflow?
- •What tools track the full lifecycle of a significant change from detection through notification acknowledgment by all parties?
- •How do you maintain a current and verified distribution list for all necessary parties (FedRAMP, agencies, 3PAO) who must receive notifications?
- •Are significant changes tracked in a centralized log that correlates with deployment records and configuration management data?
Continuous Evidence & Schedules:
- •How do you prove that every significant change in the past 12 months resulted in timely notification to all required parties?
- •Is the significant change log and notification history available as structured data via API, or only as email records and documents?
- •How do you detect significant changes that occurred but were not reported — do you have retrospective audits or drift detection?
- •What evidence demonstrates that impact assessments are completed before notifications are sent, not after?
Update History
Ask AI
Configure your API key to use AI features.