The RMF Process. Authorization Forged from Continuous Posture.

The Risk Management Framework (RMF) is the structured process published in NIST Special Publication 800-37 Revision 2 for managing security and privacy risk throughout the system development lifecycle. It is not a control catalog. It is a process that consumes control catalogs, primarily NIST 800-53 rev5, and produces authorization decisions. Federal agencies are required to follow RMF under the Federal Information Security Modernization Act (FISMA). The Department of Defense uses RMF as codified in DoDI 8510.01. The intelligence community follows a tailored version through ICD 503. Commercial organizations adopt RMF voluntarily when they operate systems on behalf of federal agencies, pursue FedRAMP authorization, or contract with the DoD. The framework establishes seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor. Each step has defined inputs, activities, and outputs. The process is iterative. Authorization is not a one-time event. It is a continuous cycle where monitoring feeds back into assessment, which informs re-authorization decisions. NIST 800-37 Rev 2, published in December 2018, added the Prepare step and elevated supply chain risk management as a first-class concern throughout the lifecycle.

The distinction between RMF and NIST 800-53 is critical and frequently confused. NIST 800-53 rev5 is a catalog of over 1,000 security and privacy controls organized into 20 families. RMF is the process that determines which of those controls apply to a given system, how they should be implemented, whether they are operating effectively, and whether the residual risk is acceptable for authorization. Confusing the two leads organizations to treat authorization as a checklist exercise: enumerate the controls, mark them complete, generate a document, obtain a signature. That approach produces System Security Plans that describe intentions rather than implementations. It produces evidence packages that reflect a point in time rather than operational reality. It produces authorization decisions based on documentation review rather than risk assessment. The consequence is an Authority to Operate (ATO) that certifies a security posture the system may never have achieved or has already drifted away from. RMF exists to prevent exactly this outcome. Each step in the process is designed to build on the previous step's outputs, creating a chain of decisions grounded in assessed risk rather than claimed compliance.

Redoubt Forge maps the complete RMF lifecycle to platform capabilities that execute each step with evidence from connected infrastructure. Rampart serves as the compliance workspace where categorization, control selection, assessment results, and authorization packages are managed. Sentinel discovers your environment, monitors posture continuously, detects drift, and collects evidence from running systems. Artificer provides intelligence throughout the process: guiding preparation with targeted questions, recommending categorization based on information types, generating control implementation narratives from observed infrastructure state, and assembling authorization documents. Citadel provides the aggregated dashboard and action queue that surfaces the highest-priority work across every RMF step. The platform does not replace the judgment required at each step. It replaces the manual labor of evidence collection, document assembly, cross-reference maintenance, and posture tracking that consumes most of the effort in traditional RMF implementations.

Preparation is the foundation step added in NIST 800-37 Rev 2. It operates at two levels: organization-wide and system-specific. At the organization level, preparation involves establishing a risk management strategy, identifying key stakeholders and their roles (Authorizing Official, System Owner, Information System Security Officer, Chief Information Security Officer), conducting an organization-wide risk assessment, and defining common controls that apply across multiple systems. At the system level, preparation involves defining the authorization boundary, identifying the system's mission and business functions, determining the information types the system will process, and identifying stakeholders who will participate in the authorization process. The Prepare step also requires identifying any existing security and privacy requirements that apply from legislation, executive orders, directives, policies, standards, or regulations. The outputs of this step feed directly into categorization: without a clear authorization boundary, categorization cannot accurately scope the impact analysis. Without identified common controls, each system reinvents protections that could be inherited.

Organizations routinely skip preparation. They move directly to categorization because the urgency of obtaining an ATO pushes teams past the foundational work. The consequences cascade through every subsequent step. Without organization-level common control identification, each system independently implements and documents controls that should be inherited from shared infrastructure: centralized identity providers, logging pipelines, network security architectures, physical security controls, personnel security programs. This duplication multiplies the evidence collection burden and creates inconsistencies when the same control is described differently across system authorization packages. Without clear authorization boundaries established during preparation, categorization scopes either too broadly (inflating the control baseline and assessment burden) or too narrowly (leaving components unprotected and unassessed). Without defined roles, authorization decisions lack clear accountability. The Authorizing Official may not understand their risk acceptance responsibility. The System Owner may not understand the boundary between their system and shared services. The ISSO may not have the access or authority needed to collect evidence and assess controls.

Sentinel begins preparation by discovering the environment. It enumerates resources across connected accounts and infrastructure, identifying compute instances, storage systems, network configurations, identity providers, and data flows. Garrison displays the discovered estate as a live inventory, giving the organization a factual picture of what exists before defining what should be in scope. Rampart captures organization-level policies, common control definitions, and inheritance relationships. When the organization defines a common control (centralized logging, identity federation, network segmentation), Rampart makes that control available for inheritance by every system registered on the platform. Artificer guides the preparation process with targeted questions about organizational structure, existing risk management practices, risk tolerance thresholds, and security infrastructure already in place. Artificer adapts its questions based on what Sentinel has already discovered, so the preparation process builds on observed reality rather than starting from a blank document. The result is a preparation record that feeds directly into categorization with defined boundaries, identified common controls, and established roles.

System categorization determines the security impact level that governs the entire authorization. The process follows FIPS 199 (Standards for Security Categorization of Federal Information and Information Systems) and NIST SP 800-60 (Guide for Mapping Types of Information and Information Systems to Security Categories). For each information type the system processes, stores, or transmits, the organization assigns impact levels across three security objectives: Confidentiality (the potential impact of unauthorized disclosure), Integrity (the potential impact of unauthorized modification or destruction), and Availability (the potential impact of disruption to access or use). Each objective receives a rating of Low, Moderate, or High. The system's overall categorization takes the high-water mark across all information types and all three objectives. A system that processes one Moderate-confidentiality information type and ten Low-confidentiality types is categorized as Moderate. The categorization directly determines the NIST 800-53 baseline (Low, Moderate, or High) that applies, which dictates the number and rigor of controls the system must implement, assess, and maintain.

Categorization errors are among the most expensive mistakes in the RMF process because they propagate through every subsequent step. Over-categorization is common in organizations that default to High impact when uncertain. A High categorization triggers the NIST 800-53 High baseline, which includes significantly more controls and more stringent implementation requirements than Moderate. Every additional control adds implementation cost, evidence collection overhead, assessment time, and ongoing monitoring burden. For systems that genuinely handle only Low or Moderate impact information, this inflated baseline wastes resources that could be directed toward actual risk reduction. Under-categorization is more dangerous. A system categorized as Low that actually handles Moderate-impact information will implement an inadequate baseline, leaving gaps that represent real security risk and potential FISMA non-compliance. Incomplete information type analysis is the root cause of both errors. Organizations that categorize based on the system's primary function without analyzing all information types that flow through it will miss information types that elevate the categorization. A system designed for Low-impact administrative data that also processes personnel records containing PII may warrant a Moderate categorization that the cursory analysis missed.

Rampart structures the categorization process around NIST 800-60 information type mappings. The system owner selects information types from the catalog, and Artificer guides the analysis with targeted questions about how each information type is processed. Artificer asks about data sources, data flows, retention requirements, access populations, and downstream systems that receive information. Based on the responses and the NIST 800-60 recommended impact levels for each information type, the platform computes the provisional categorization. Artificer highlights cases where the recommended impact level may need adjustment based on organizational context: a mission-critical availability requirement that exceeds the default recommendation, or a confidentiality concern driven by aggregation effects where individually Low-impact records become Moderate when combined. The categorization record in Rampart links directly to the baseline derivation in the next step. When categorization changes (new information types added, impact levels revised after further analysis), the control baseline updates automatically to reflect the new categorization. The entire chain from information type through impact level through baseline selection is traceable and auditable.

Control selection begins with the baseline derived from categorization. A Moderate-impact system receives the NIST 800-53 rev5 Moderate baseline, which specifies approximately 325 controls and control enhancements across 20 families. The baseline is a starting point, not the final control set. Tailoring adjusts the baseline to the system's specific context. Organizations may add controls beyond the baseline when risk assessment identifies threats not adequately addressed. Organizations may assign specific values to control parameters left open by the catalog (password length, audit retention periods, session timeout durations). Organizations may apply overlays that modify the baseline for specific operational contexts: DISA STIGs for specific operating systems and applications, DISA SRGs for technology categories, CIS Benchmarks for hardening standards, FedRAMP-specific parameter requirements, DoD Impact Level requirements, and organizational overlays that reflect enterprise policy decisions. The tailored control set, with all parameter assignments resolved and all overlays applied, becomes the security control baseline against which the system will be implemented, assessed, and authorized.

Tailoring without documentation is one of the most common RMF failures. When an organization removes a control from the baseline or adjusts a parameter, the rationale must be documented and approved. Undocumented tailoring decisions create gaps that assessors flag as findings: the control is absent from the implementation, and there is no record explaining why. Overlay application introduces version control complexity. A system may need to satisfy the NIST 800-53 Moderate baseline, a FedRAMP Moderate overlay, a DISA RHEL 9 STIG overlay, and an organizational overlay simultaneously. These overlays can conflict: one overlay may require a 15-minute session timeout while another specifies 10 minutes. Manual resolution of these conflicts is error-prone and produces parameter assignments that lack traceability to their source overlay. Missing organizational parameter assignments leave controls incomplete. NIST 800-53 deliberately leaves certain values as "organization-defined" (e.g., "the organization reviews access privileges [organization-defined frequency]"). If the organization never assigns a specific frequency, the control cannot be fully implemented or assessed because the success criterion is undefined.

Rampart derives the initial baseline automatically from the categorization completed in the previous step. A Moderate categorization produces the NIST 800-53 rev5 Moderate baseline with all applicable controls enumerated. The platform then applies overlays through a composition engine that stacks multiple overlays with explicit conflict resolution. When two overlays specify different values for the same parameter, Rampart flags the conflict and presents the options with their source overlay identified. Artificer recommends tailoring decisions based on the system's mission, technology stack, and deployment environment. Artificer identifies controls that are candidates for removal with rationale (physical security controls for a cloud-only system, for example) and recommends parameter assignments based on organizational context and framework requirements. Every tailoring decision is recorded with its rationale, the identity of the person who approved it, and a timestamp. The resulting tailored baseline is version-controlled. When an overlay updates (a new STIG revision, a revised FedRAMP requirement), Rampart identifies which controls changed and what the impact is on the system's tailored baseline. The delta is presented for review rather than requiring a manual comparison between overlay versions.

Control implementation is where the tailored baseline becomes operational reality. Each selected control must be implemented in the system's environment and documented in the System Security Plan (SSP). Implementation spans three domains. Technical controls are enforced through hardware, software, and firmware: access control mechanisms, encryption, audit logging, network segmentation, intrusion detection, configuration management. Administrative controls are enforced through policies, procedures, and organizational processes: security awareness training, incident response plans, personnel security screening, risk assessment procedures, configuration change management. Physical controls are enforced through facility protections: access control to server rooms, environmental monitoring, media protection and sanitization. The SSP documents how each control is implemented, who is responsible for maintaining it, and where the evidence of its operation can be found. For inherited common controls identified during the Prepare step, the SSP references the provider system's implementation rather than duplicating the description. Implementation is not just deployment. A technical control that is deployed but not configured correctly is not implemented. A policy that is written but not distributed, trained, and enforced is not implemented.

Implementation without concurrent documentation is a pattern that delays authorization by months. Technical teams deploy infrastructure, configure security controls, and move to the next task without documenting what they built, why they built it that way, or how it satisfies the specific control requirement. When the SSP is written later (often by a different person), the documentation describes the intended implementation rather than the actual one. Discrepancies between the SSP narrative and the deployed configuration become assessment findings. Infrastructure-only focus is another common failure. Organizations invest heavily in technical controls while neglecting the administrative and physical controls in the baseline. A Moderate baseline includes controls for security awareness training (AT-2), personnel screening (PS-3), incident response testing (IR-3), contingency plan testing (CP-4), and media sanitization (MP-6). These require organizational processes, not technology. Organizations that treat implementation as purely an engineering exercise arrive at the Assess step with strong technical posture and significant gaps in administrative and physical controls. Policies that are written but not enforced represent a particular risk. An access review policy that requires quarterly reviews does not satisfy AC-2 if the reviews are not actually conducted and documented.

Armory provides hardened infrastructure-as-code modules for technical controls. Each module is mapped to the specific NIST 800-53 controls it satisfies, with STIG parameters and CIS Benchmark configurations built in. Deploy the encryption module, and SC-28 (Protection of Information at Rest) is satisfied by design. Deploy the logging module, and AU-2 (Audit Events), AU-3 (Content of Audit Records), AU-6 (Audit Review, Analysis, and Reporting), and AU-12 (Audit Generation) are satisfied from the first deployment. The infrastructure IS the evidence. Vanguard scans implementations against the tailored baseline, identifying configuration drift between the intended state and the deployed state. Sentinel monitors deployments continuously, detecting when infrastructure changes affect control satisfaction. Artificer generates SSP implementation narratives from observed infrastructure state: not a generic description of access control, but a specific narrative that references the identity provider in use, the role-based access control policies applied, the specific IAM configurations deployed, and the evidence artifacts that demonstrate enforcement. The narrative updates as the implementation changes, keeping the SSP synchronized with reality rather than frozen at the time of initial documentation.

Assessment evaluates whether implemented controls are operating as intended and producing the desired security outcome. The step begins with the Security Assessment Plan (SAP), which defines the assessment scope, methodology, procedures, and schedule. The SAP specifies which controls will be assessed, the assessment methods for each (examine, interview, test), the assessment objects (specifications, mechanisms, activities, individuals), and the level of assessment effort (basic, focused, comprehensive). Assessment execution applies those methods to each control. Examining involves reviewing documentation, configurations, and artifacts. Interviewing involves questioning personnel responsible for implementing and operating controls. Testing involves exercising controls to determine whether they function as described. The results are compiled into a Security Assessment Report (SAR), which documents findings for each assessed control: satisfied, other than satisfied, or not assessed. The SAR feeds directly into the authorization decision by providing the Authorizing Official with an evidence-based picture of security posture and residual risk.

Assessment plans that test implementation but not effectiveness miss the purpose of the Assess step. A control can be implemented (the technology is deployed, the policy is written) without being effective (the technology is misconfigured, the policy is not followed). AC-2 (Account Management) is not satisfied by having an identity provider. It is satisfied when account types are defined, managers are assigned, conditions for group and role membership are established, access is authorized before accounts are created, accounts are reviewed at the organization-defined frequency, and accounts are disabled when no longer needed. Assessing only whether the identity provider exists tests implementation. Assessing whether account reviews are conducted on schedule, whether disabled accounts are actually disabled, and whether role assignments match current job functions tests effectiveness. Relying on a single point-in-time snapshot ignores operational variability. A configuration that passes assessment on Monday may drift by Wednesday. An access review completed the week before assessment may not have been conducted for the six months prior. Assessment independence is another concern. Self-assessments conducted by the same team that implemented the controls lack the objectivity that assessors and Authorizing Officials rely on for risk decisions.

Rampart computes per-control assessment scores across three independent dimensions. Defense effectiveness measures whether the control is actively producing its intended security outcome in the running environment. Evidence coverage measures the completeness and specificity of artifacts that demonstrate control operation: configuration snapshots, scan results, policy documents, access review logs, training records. Evidence freshness measures how current those artifacts are, because a configuration snapshot from six months ago does not demonstrate current effectiveness. Sentinel provides continuous evidence streams that keep assessment data current throughout the assessment period, not just at the moment of collection. The platform generates assessment packages with full provenance chains: each finding traces back through the evidence artifact, the source system that produced it, the collection timestamp, and the integrity verification. Artificer identifies controls where the evidence suggests implementation without effectiveness, flagging patterns like access review policies that exist without corresponding review records, or logging configurations deployed without evidence of log analysis. The assessment output feeds directly into the authorization decision with per-control scoring that distinguishes between strong controls with fresh evidence and weak controls with stale or missing proof.

Authorization is the decision point where the Authorizing Official (AO) accepts the residual risk of operating the system based on the assessment results. The AO reviews the complete authorization package: the System Security Plan describing the system and its controls, the Security Assessment Report documenting assessment findings, and the Plan of Action and Milestones (POA&M) documenting known gaps with remediation plans. Three outcomes are possible. ATO (Authority to Operate) authorizes the system for operation, typically for a defined period or under continuous authorization terms. DATO (Denial of Authorization to Operate) means the residual risk exceeds the AO's risk tolerance and the system may not operate until gaps are remediated. IATT (Interim Authorization to Test) allows limited operation under restricted conditions for testing or evaluation purposes. The authorization decision is a risk acceptance, not a compliance certification. The AO is personally accountable for the risk they accept. An ATO does not mean the system has no vulnerabilities. It means the AO has reviewed the residual risk, determined it falls within acceptable bounds given the system's mission, and accepted responsibility for that risk with documented mitigations for known gaps.

Authorizing Officials frequently receive incomplete risk pictures. Authorization packages assembled manually under time pressure contain inconsistencies: the SSP describes controls that the SAR found deficient, the POA&M lists items that are already remediated but not updated, evidence artifacts reference system components that no longer exist in the current architecture. The AO must make a risk decision based on this package, and incomplete or inconsistent information leads to either excessive caution (denying authorization for systems that are actually well-protected but poorly documented) or misplaced confidence (authorizing systems where the documentation looks complete but does not reflect operational reality). POA&Ms frequently lack actionable remediation plans. An entry that states "implement multi-factor authentication" without specifying the technology, the integration points, the user population, the timeline, the resources required, and the responsible party is not a plan. It is a wish. Realistic timelines are another chronic weakness. Organizations commit to remediation schedules that ignore procurement cycles, change management windows, testing requirements, and competing priorities. The AO accepts these timelines, and the system enters operation with POA&M items that will not close on schedule.

Rampart delivers a complete authorization package with per-control scoring, evidence chains, and POA&M tracking integrated into a single workspace. The AO or their designated representative can navigate every control, examine the assessment findings, drill into the evidence provenance, and review the POA&M with remediation progress tracked in real time. Each POA&M item includes the specific control affected, the finding detail, the remediation plan with technical steps, the responsible party, the target closure date, and linked evidence showing progress toward remediation. Alliance provides scoped read-only access for assessors and AO staff. The assessor navigates controls, evidence, and findings independently. Every action within Alliance is logged, creating a chain of custody for the assessment and authorization review. Artificer generates risk summaries from assessment data, highlighting the highest-risk findings, the controls with the weakest evidence, and the POA&M items that carry the most posture impact. The authorization package is not a static document compiled once. It is a living view that the AO can revisit at any point during the authorization period to assess whether the risk picture has changed.

Continuous monitoring is the final RMF step and the one that sustains authorization between assessment cycles. NIST SP 800-137 (Information Security Continuous Monitoring for Federal Information Systems and Organizations) defines the framework for ongoing assessment of security controls, awareness of threats and vulnerabilities, and timely response to security-relevant events. Post-authorization monitoring encompasses several activities: ongoing assessment of a subset of security controls on a defined schedule, monitoring for security-relevant changes to the system and its environment, conducting impact analyses of proposed or actual changes, tracking the status of POA&M items and verifying remediation, reporting the security status of the system to the Authorizing Official, and responding to incidents that may affect the system's risk posture. The monitoring strategy must specify which controls will be assessed, how frequently, using which assessment methods, and who is responsible for each. The strategy must account for the relative volatility of different controls: technical controls that can be assessed automatically may be monitored weekly or continuously, while administrative controls that require interviews may be assessed quarterly or annually.

Post-ATO monitoring degrades to annual reviews in many organizations. The assessment team disbands. The ISSO returns to other duties. Evidence collection stops until the next assessment cycle approaches. Infrastructure continues to change: new services are deployed, existing configurations are modified, personnel rotate, and the authorization boundary shifts as the system evolves. None of these changes trigger a compliance impact assessment because the monitoring process is not actually operating. Evidence goes stale. Configuration snapshots from the authorization date no longer reflect the running system. Access review records stop being generated because the reviews are not being conducted. The gap between the point-in-time ATO and the continuous operational reality widens month by month. When the next assessment cycle arrives (or when an incident triggers an unscheduled review), the organization discovers that its documented posture no longer matches its actual posture. The re-authorization effort becomes nearly as large as the initial authorization because the continuous monitoring that was supposed to maintain currency was not maintained. The concept of ongoing authorization, where the AO maintains continuous visibility and makes risk decisions in real time rather than periodically, remains aspirational for organizations that lack the tooling to sustain it.

Sentinel maintains continuous posture monitoring and evidence freshness across every connected infrastructure source. When a configuration changes on a monitored resource, Sentinel evaluates the compliance impact immediately: which controls does this resource support, and does the new configuration still satisfy them? Drift detection fires in real time. If an encryption configuration is removed from a storage resource, Sentinel maps that change to the affected controls and flags the degradation. For certain infrastructure drift scenarios, Sentinel can auto-remediate after approval, restoring the compliant state within defined change windows. Evidence freshness automation prevents gaps from forming: when evidence approaches its expiration threshold, Sentinel re-collects from continuous sources automatically. Rampart recalculates control scores as evidence updates arrive, maintaining a living assessment that reflects current posture rather than the posture at authorization time. The AO can review the system's security status at any point through the authorization package, which updates continuously rather than being frozen at the assessment date. Citadel surfaces monitoring events, drift alerts, and evidence expiration warnings in the action queue, ensuring that security-relevant changes receive attention when they occur rather than accumulating until the next review cycle. The result is ongoing authorization sustained by continuous evidence, not periodic re-authorization driven by expired documentation.

RMF does not exist in isolation. It is the process layer that connects multiple framework and regulatory requirements into a unified authorization lifecycle. NIST 800-53 rev5 is the control catalog that RMF consumes. When an organization follows RMF, the Select step draws controls from NIST 800-53 based on the system's categorization. FedRAMP is an instantiation of RMF for cloud service offerings. FedRAMP uses the same NIST 800-53 baselines (Low, Moderate, High) but adds FedRAMP-specific parameter assignments, additional requirements, and a distinct assessment and authorization process through the Joint Authorization Board or agency-level authorization. CMMC uses a different assessment methodology but overlapping controls: CMMC Level 2 maps to NIST 800-171 rev2, which derives from the NIST 800-53 Moderate baseline. FISMA is the federal law that mandates RMF for federal information systems and requires agencies to develop, document, and implement information security programs. FISMA does not define how to secure systems. It requires agencies to follow NIST standards and guidelines, which means RMF. Understanding these relationships is essential because work done under one framework reduces the effort required for others.

Reciprocity is the principle that one authorization should reduce the effort for subsequent authorizations across systems and organizations. If a cloud service provider achieves a FedRAMP Moderate authorization, an agency that wants to use that service should be able to leverage the existing authorization rather than conducting a full independent assessment. In practice, reciprocity is limited. Different Authorizing Officials have different risk tolerances. Agency-specific requirements may exceed the FedRAMP baseline. The authorization boundary for the cloud service may not cover all the ways the agency plans to use it. Nevertheless, the underlying control work transfers. The FedRAMP authorization demonstrates that specific NIST 800-53 controls are implemented and assessed. An agency conducting its own RMF process can inherit those controls and focus its assessment on system-specific implementations and agency-specific requirements. The same principle applies within an organization. A system that achieves an ATO under the Moderate baseline has demonstrated satisfaction of controls that overlap with the High baseline. If a second system requires a High categorization, the work already done on common controls and shared infrastructure transfers. Reciprocity compounds across the organization's portfolio as more systems are authorized and more common controls are documented.

Rampart resolves the relationships between RMF and all derived frameworks through five mapping strategies: native control mapping (direct relationships published by the framework authority), NIST 800-53 derivation chain tracing (following the path from any framework back through 800-53 to any other framework that derives from it), NIST CSF 2.0 bridging (using the Cybersecurity Framework as an intermediary between frameworks that lack direct mappings), published cross-walks from authoritative sources, and AI-suggested mappings that require human confirmation before activation. Work completed during one RMF authorization compounds across the entire compliance portfolio. When controls are assessed and evidence collected for one system's ATO, Rampart computes the readiness impact on every other framework and system registered on the platform. The marginal effort to add each subsequent framework decreases because the control overlap compounds through the derivation chain. Common controls documented during the Prepare step are inherited automatically by every system that shares the same infrastructure. Artificer identifies reciprocity opportunities: when a new system enters the authorization process, Artificer surfaces which controls are already satisfied by common controls, shared infrastructure, and existing authorizations, quantifying the work that has already been done and highlighting the delta that remains. One security posture. Every framework computed. Every authorization leveraged.