FedRAMP provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. While the program’s rigorous baseline requirements ensure consistent security, the reality is that this consistency calls for a little flexibility.
This is where deviation requests and significant change requests come into play.
These two mechanisms enable CSPs to adapt their systems while maintaining compliance and security integrity, serving as a crucial way for companies to meet FedRAMP requirements.
Understanding the FedRAMP Framework
FedRAMP establishes three impact levels (Low, Moderate, and High), each with corresponding security control baselines derived from NIST SP 800-53. These controls cover everything from access management and encryption to incident response and system monitoring. In that way, they seem comprehensive, if not rigid.
However, a one-size-fits-all approach can hinder innovation without enhancing security. FedRAMP recognizes that and has built in processes to handle exceptions and modifications, ensuring the program remains both secure and practical.
What Are Deviation Requests?
A deviation request is a formal proposal to implement a security control differently than specified in the FedRAMP baseline or, if possible, to implement a compensating control in place of a required control. Essentially, it’s asking for permission to deviate from the standard implementation while maintaining an equivalent or acceptable level of security.
Deviation requests are not about lowering security standards. Instead, they acknowledge that different technical architectures, operational environments, or business models may require alternative approaches to achieving the same security objectives. The key is demonstrating that the proposed deviation maintains adequate risk management and doesn’t create unacceptable vulnerabilities.
Common scenarios that might warrant a deviation request include:
- Architectural Limitations: When the cloud service’s fundamental architecture makes a standard control implementation impractical or impossible.
- Compensating Controls: Situations where alternative security measures provide equivalent or superior protection.
- Operational Constraints: Cases where standard implementation would significantly impair service functionality without proportionate security benefits.
- Technology-Specific Considerations: Instances where emerging technologies or unique platforms require different security approaches.
For example, a containerized microservices architecture might require different approaches to boundary protection than traditional virtual machine environments. Rather than forcing the use of inappropriate controls, a well-justified deviation request enables the CSP to implement security measures that align with the actual technology stack.
The Deviation Request Process
A submission for a deviation request requires detailed documentation that explains not only what they want to do differently, but why the alternative approach maintains appropriate security.
Key aspects of this request include:
- Technical Rationale: The CSP must explain why the standard control implementation is problematic or infeasible in the specific context. This goes beyond simply stating difficulty… it requires demonstrating fundamental incompatibility or disproportionate impact. The documentation should also describe the proposed alternative implementation in detail, showing exactly how security will be maintained through different means.
- Risk Analysis: This forms a critical component of any deviation request. The CSP must assess the risks that arise from not implementing the control as specified and how the proposed alternative mitigates those risks. This analysis should be thorough and honest, acknowledging any residual risks while demonstrating that they remain within acceptable bounds.
- Approval process involvement: Multiple stakeholders review deviation requests. For Agency authorizations, the Authorizing Official (AO) makes the final decision, often in consultation with the Agency’s information security team. For JAB authorizations, the request goes through the JAB’s technical review process. Third-party assessment organizations may also contribute to the assessment phase.
Importantly, deviation requests do not guarantee approval. Reviewers scrutinize these requests carefully, and weak justifications or proposals that genuinely compromise security will be rejected. CSPs should be prepared to engage in dialogue, answer questions, and potentially revise their proposals in response to feedback.
Understanding Significant Change Requests
While deviation requests address how you implement controls, significant change requests deal with modifications to the cloud system itself after it receives FedRAMP authorization. A significant change is any modification that could materially impact your system’s security posture, risk profile, or the validity of existing authorization. The AO must review and approve these changes before you implement them.
The challenge lies in determining what qualifies as a “significant” change. Changes that clearly meet the threshold include:
- Major Architectural Changes: Implementing new system components, modifying the system boundary, or significantly altering the system’s operation.
- New Services or Features: Adding functionality that wasn’t part of the original authorization, especially if it involves new data processing or user interactions.
- Infrastructure Modifications: Moving to new data centers, changing cloud hosting providers, or significantly altering the underlying infrastructure.
- Control Implementations: Modifying how you implement security controls, particularly if those changes affect multiple controls.
- Integration Changes: Adding new interconnections with external systems or significantly modifying existing integrations.
Routine maintenance, patches that don’t alter system functionality, and minor configuration adjustments typically don’t trigger the significant change process.
The Significant Change Request Process
When a CSP identifies a needed change that appears significant, the process starts with documentation. The CSP prepares a detailed change request describing the proposed modification, its purpose, business justification, and potential security implications. This requires a thorough analysis of how the change affects the system’s security controls, data flows, and overall risk posture.
Strong change request documentation addresses several key areas. It clearly describes what’s changing at both technical and functional levels. It analyzes security impact, identifying which controls might be affected and how. It proposes necessary updates to security documentation, including the SSP.
Once submitted, the request enters review. The AO, often supported by technical staff and potentially the 3PAO, evaluates whether the change is truly significant and acceptable from a security standpoint.
This review may include:
- Assessing whether existing controls remain adequate or if new controls are needed.
- Evaluating whether the change falls within acceptable risk parameters.
- Determining whether additional testing or assessment is required.
- Deciding whether updated authorization documentation is necessary.
Approval timelines vary based on change complexity and stakeholder responsiveness.
Best Practices for Managing Both Processes
Successfully navigating deviation and significant change requests requires a proactive, strategic approach. These key practices will set you up for success:
- Maintain Open Communication. Build relationships with your AOs before requests become urgent. When you anticipate changes or deviations well in advance, there’s time for thoughtful discussion and collaboration rather than rushed decision-making.
- Prioritize Documentation Quality. Both deviation and significant change requests demand clear, comprehensive, technically accurate documentation. Vague or incomplete submissions lead to delays, rejections, or endless rounds of clarifying questions. Invest time in thorough initial documentation.
- Develop Internal Identification Processes. Establish mechanisms for recognizing when deviations or significant change requests are needed. Train technical teams to spot potential issues during system design and implementation. Create clear escalation paths when questions arise so nothing slips through the cracks.
- Maintain Detailed Records. Keep comprehensive records of all approved deviations and significant changes for ongoing compliance. Reference these approvals in your System Security Plan and other authorization documentation so future assessors and reviewers understand your system’s complete security implementation.
Trust Lazarus Alliance to Help With Your FedRAMP Journey
Deviation and significant change requests represent critical flexibility mechanisms within FedRAMP’s rigorous security framework. They acknowledge that security isn’t about rigid adherence to specifications but about achieving risk management objectives in ways that align with real-world technology and operational constraints.
To learn more about how Lazarus Alliance can help, contact us.
- FedRAMP
- StateRAMP
- NIST 800-53
- FARS NIST 800-171
- CMMC
- SOC 1 & SOC 2
- HIPAA, HITECH, & Meaningful Use
- PCI DSS RoC & SAQ
- IRS 1075 & 4812
- ISO 27001, ISO 27002, ISO 27005, ISO 27017, ISO 27018, ISO 27701, ISO 22301, ISO 17020, ISO 17021, ISO 17025, ISO 17065, ISO 9001, & ISO 90003
- NIAP Common Criteria – Lazarus Alliance Laboratories
- And dozens more!
What Is Autonomous Malware?
We’re reaching the end of 2025, and looking ahead to 2026, most experts are discussing the latest threats that will shape the year ahead. This year, we’re seeing a new, but not unexpected, shift to autonomous threats driven by state-sponsored actors and AI. With that in mind, a new generation of threats, broadly known as...Continue reading→
What CISA’s Emergency Directive 26-01 Means for Everyone
In mid-October 2025, the CISA issued one of its most urgent orders yet: Emergency Directive 26-01. The directive calls on all Federal Civilian Executive Branch (FCEB) agencies to immediately mitigate vulnerabilities in devices from F5 Networks following a state-sponsored breach of F5’s systems and access to portions of BIG-IP source code and vulnerability data. The event...Continue reading→
Cybersecurity and Vetting AI-Powered Tools
A recent exploit involving a new AI-focused browser shone a light on a critical problem–namely, that browser security is a constant issue, and AI is just making that threat more pronounced. Attackers discovered a way to use that browser’s memory features to implant hidden instructions inside an AI assistant. Once stored, those instructions triggered unwanted...Continue reading→
Shutdown Security And Cyber Vulnerability
When the federal government shuts down, the public sees closed monuments, unpaid workers, and halted programs. What they do not see is the silent surge of cyberattacks targeting agencies already operating on fumes. During the most recent shutdown, attacks against U.S. government systems spiked by nearly 85%. Cybersecurity failures during government disruptions rarely start with...Continue reading→
Identity and the Shift from Malware
The world of cyber threats is rapidly evolving, and while we can see these changes more generally, it’s always crucial to understand them concretely. As the 2025 CrowdStrike Global Threat Report shows us, the landscape of our industry is changing. We’re digging into this report to discuss a challenging trend: the move of hackers foregoing...Continue reading→
Maintaining Compliance Against Prompt Injection Attacks
The increasing adoption of AI by businesses introduces security risks that current cybersecurity frameworks are not prepared to address. A particularly complex emerging threat is prompt injection attacks. These attacks manipulate the integrity of large language models and other AI systems, potentially compromising security protocols and legal compliance. Organizations adopting AI must have a plan...Continue reading→
Are We Already Talking About CMMC 3.0?
The ink has barely dried on the CMMC final rule, and already the defense contracting community is buzzing with speculation about what comes next. Just when contractors thought they had a moment to catch their breath after years of regulatory limbo, whispers of CMMC 3.0 have begun circulating through the industry. But is this just...Continue reading→
Centralizing Identity-Based Risk
As the traditional network boundary dissolves and remote work becomes standard practice, identities are the major frontier for security. Whether we’re talking about human users, service accounts, or machine identities, these have emerged as both the primary access mechanism and the most targeted attack vector. It has become imperative for providers to centralize identity management...Continue reading→
The Costs of Compliance and Data Breaches
Data is possibly one of the most valuable assets any organization holds. Customer information, employee records, and proprietary business intelligence present challenges because the data flowing through modern enterprises represents both significant opportunities and serious risks. Businesses face a challenging balance: investing in compliance measures to protect sensitive information while also preparing for the real...Continue reading→
Security-First Service Architecture for MSPs
The world of managed services is changing fast. In the past, providers focused on cost and efficiency, adding security as an afterthought. But that doesn’t work anymore. The threat landscape today demands something entirely different: an approach where security isn’t an extra, but is baked into every layer of how an MSP designs and delivers...Continue reading→
Related Posts