An In Process Request is the formal notice that an agency and cloud service provider are beginning the FedRAMP authorization process together. It documents the service name, impact level, points of contact, assessment timing, and the agency’s intent to work toward an ATO. It is a control point for scope and coordination.
Expanded Definition
An In Process Request is a coordination artifact used in the FedRAMP pathway to show that a federal agency and a cloud service provider have formally started work toward authorization. It is not the authorization itself, and it does not replace the System Security Plan, security assessment, or Authority to Operate decisions that follow. The value of the request is that it establishes a shared scope, identifies the service offering, records the planned assessment window, and confirms which agency is sponsoring the effort. In practice, it functions as an early governance checkpoint that helps prevent mismatched expectations about impact level, boundaries, and responsibilities.
The concept is still procedural rather than a universal security control, so definitions and handling can vary across programs and supporting documentation. For teams looking for the broader cybersecurity governance context around risk management, NIST Cybersecurity Framework 2.0 provides a useful reference point for how organisations structure risk and accountability. The most common misapplication is treating an In Process Request as evidence of approval, which occurs when stakeholders assume the existence of the notice means the service has already met authorization requirements.
Examples and Use Cases
Implementing this request rigorously often introduces process overhead, requiring organisations to balance faster onboarding against tighter coordination and documentation discipline.
- A federal agency agrees to sponsor a cloud service and files the request before assessment planning begins, so both parties share the same authorization target.
- A provider uses the request to lock down the proposed service boundary, helping avoid later disputes about which modules, tenants, or environments are in scope.
- A FedRAMP Program Management Office reviews the notice to confirm the service is progressing through the correct path and that the impact level is documented consistently.
- Security and compliance teams use the request as an early checkpoint to align evidence collection, testing dates, and point-of-contact responsibilities.
- In larger multi-stakeholder programmes, the notice helps prevent duplicate work by creating a single source of truth for the current authorization status and next steps.
Because the request is an entry point rather than an outcome, its usefulness depends on what happens after filing. Program teams often pair it with formal control mapping and evidence preparation so that the authorisation track remains coherent from the first sponsor commitment through the final review.
Why It Matters for Security Teams
Security teams need to understand an In Process Request because it marks the point where authorization risk becomes operational, not theoretical. If the notice is vague or incomplete, the programme can drift into scope confusion, delayed assessments, and disagreements about whether the service is actually ready for review. That creates downstream problems in evidence quality, control ownership, and remediation timing. For cloud services with shared responsibility boundaries, the request also helps clarify where the provider’s obligations end and the agency’s oversight begins.
This matters most when identity and access decisions depend on the authorization boundary, because misaligned scope can affect how accounts, administrators, and service connections are reviewed later in the process. It is also relevant to third-party governance, where procurement, security, and legal stakeholders need a common reference for status and sponsorship. The broader lesson is that a formal notice is not paperwork for its own sake; it is the point at which accountability must be assigned before technical review starts. Organisations typically encounter the cost of a weak request only after assessment findings, at which point the missing clarity becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while DORA and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance oversight fits the request's role as a formal authorization coordination point. |
| NIST SP 800-53 Rev 5 | CA-2 | Assessment planning aligns with security control assessment initiation and scope definition. |
| NIST SP 800-63 | Identity assurance is relevant when the authorization boundary includes user or admin access. | |
| DORA | Operational resilience programs also rely on documented coordination before formal risk acceptance. | |
| NIS2 | NIS2 emphasizes managed security processes that benefit from documented pre-authorization coordination. |
Record sponsor, scope, and timing early so operational accountability is clear before assessment work starts.
Related resources from NHI Mgmt Group
- What breaks when pull_request_target workflows process untrusted input?
- Who is accountable when a business fails to process a centralized deletion request correctly?
- What is the difference between network trust and request-level identity trust?
- Why do NHI programmes need stronger process ownership than many human identity programmes?
