The Risk Management Framework is a structured process for authorizing federal information systems to operate. Each of its seven steps produces a specific artifact, and each artifact becomes the input to the next step. The scenario below uses a simple internal HR application that stores employee records: names, SSNs, salary information, and performance reviews. Walking RMF through this system end to end makes the abstract steps concrete.
The Seven Steps
Prepare
Establish context before any control work begins. Define the system boundary, identify stakeholders (HR owns the data, IT operates the system, leadership holds risk tolerance), and document what data types the system handles and how critical it is to the mission.
Output: System boundary and stakeholder documentationCategorize
Apply FIPS 199 to determine the system’s overall impact level, Low, Moderate, or High, based on the potential impact to Confidentiality, Integrity, and Availability. The HR system’s categorization is covered in detail below.
Output: System Categorization documentSelect
Based on the impact level from Categorize, pull the corresponding SP 800-53B control baseline and tailor it. Tailoring means adding overlays for specific requirements, removing controls that genuinely do not apply, and documenting the rationale for every change.
Output: Tailored control baselineImplement
Engineers and operations teams build the controls. The GRC role here is documentation: capturing how each control is actually implemented in the System Security Plan. The SSP is largely a GRC-authored artifact even though the implementation work is technical.
Output: System Security Plan (SSP)Assess
An independent assessor tests whether the controls described in the SSP actually work as described, not just whether they exist on paper. Where controls fail or are incomplete, those gaps get documented in a Plan of Action and Milestones rather than restarting the process.
Output: Security Assessment Report (SAR) and POA&MAuthorize
The Authorizing Official reviews the SSP, SAR, and POA&M and makes a risk-based decision. The result is an Authorization to Operate, an Interim ATO if residual risk is acceptable short-term with a remediation timeline, or a denial.
Output: Authorization to Operate (ATO)Monitor
Continuous monitoring against the baseline: control effectiveness, configuration changes, incident activity, and periodic reassessment. If something material changes, a new data type or architecture change, that can trigger a return to Categorize or Select. It rarely means starting over from Prepare.
Output: Continuous monitoring programCategorize in Detail: The High Water Mark Rule
FIPS 199 requires rating the potential impact of a loss of Confidentiality, Integrity, and Availability independently for each data type the system handles. Each gets a rating of Low, Moderate, or High based on what would happen if that property were compromised.
The HR system does not handle just one data type. It handles several, each with a different risk profile:
| Data Type | Confidentiality | Integrity | Availability |
|---|---|---|---|
| Employee SSNs and banking info | High | High | Low |
| Performance reviews | Moderate | Moderate | Low |
| Employee directory | Low | Low | Low |
| Payroll processing data | Moderate | High | Moderate |
The high water mark rule: the system’s overall category for each security objective is the highest rating assigned to that objective across all data types it handles, and the system’s overall categorization is the highest of those three.
Confidentiality’s highest rating is High, driven by SSNs and banking information. Integrity’s highest is also High, driven independently by two separate data types: SSNs and banking details being altered has direct financial and legal consequences, and payroll processing data being silently altered means people get paid the wrong amount. Availability tops out at Moderate.
This HR system categorizes as High overall, not because every piece of data it holds is highly sensitive, but because two different data types each independently push Integrity to High, and SSNs push Confidentiality to High. The directory information being Low does not pull the categorization down. The categorization is not an average. It is a ceiling set by the worst case.
A system can feel mostly low-risk and still categorize as High because of one data type. Multiple paths can lead to the same ceiling, and one High anywhere in the system makes the whole system High for that objective.
Select: From Categorization to Control Baseline
Once the HR system is categorized as High, SP 800-53B provides the High baseline, roughly 325 to 425 controls depending on the revision, versus around 125 for Low and 325 for Moderate. This is a meaningfully larger control set and a direct consequence of the Categorize step. Under-categorizing means under-controlling a system that actually needs more. Over-categorizing means burning effort on controls that do not match real risk.
Working with SP 800-53B in practice means two separate NIST documents: the control catalog describing every control and enhancement, and the baselines file mapping each impact level to which controls apply. Filtering the baselines file to the High column gives you the starting control list, which then gets tailored with documented justification for every addition or removal.
Implement: Writing the System Security Plan
Implement is where engineers build the controls and GRC documents them. The SSP describes every control in the tailored baseline, how it is implemented, who owns it, and what evidence demonstrates it is working.
IA-2(1): MFA for Privileged Access
Implemented via Okta. All admin accounts require hardware MFA or Okta Verify FastPass. Policy enforced at the application layer through SAML assertions. Password alone cannot complete authentication.
SC-28: Protection of Information at Rest
Employee records encrypted at rest using AES-256. Database encryption managed through the cloud provider’s KMS. Key rotation policy documented and enforced quarterly.
AU-2: Audit Events
All read and write operations on employee records are logged to a centralized SIEM. Log retention is 12 months hot, 24 months cold. Log access restricted to security team by IAM policy.
AC-2: Account Management
User provisioning and deprovisioning automated through HR system integration with Okta. Joiner-mover-leaver process documented and tested quarterly. Access reviews conducted every 90 days.
The SSP is a management document that describes technical implementation in plain language an assessor can evaluate. GRC writes it. Engineers validate the implementation details. The line between how it is built and how it is documented is exactly where policy meets implementation, and where gaps between the two most commonly surface during assessment.
Assess: Testing What Is in the SSP
An independent assessor takes each control and determines whether it is implemented as described, partially implemented, or not implemented at all. For the HR system that means:
- Requesting evidence of MFA enforcement, not just a policy saying it is required, but a screenshot of Okta policy configuration showing it cannot be bypassed
- Verifying encryption at rest by reviewing KMS configuration and key rotation logs, not just accepting the SSP’s assertion
- Pulling a sample of audit logs to confirm the right events are captured and retained
- Running a test offboarding to verify deprovisioning actually happens within the documented timeframe
Where a control fails or is only partially implemented, it goes into the POA&M rather than triggering a restart. The POA&M documents the gap, the risk it represents, the planned remediation, and the target date.
The Security Assessment Report documents what the assessor found: pass, fail, partial, and the evidence behind each finding. The POA&M documents what is going to be done about the failures. Both go to the Authorizing Official. The AO’s job is to decide whether the residual risk represented by the open POA&M items is acceptable, not to demand zero findings before authorizing.
Authorize: The AO’s Risk Decision
Authorization is a risk acceptance decision, not a technical one. The Authorizing Official reviews the full package and makes a judgment call: is the residual risk acceptable given the system’s mission value and the cost of further remediation?
Authorization to Operate (ATO)
Full authorization. Residual risk is acceptable. The system may operate. Typically granted for one to three years before reassessment is required.
Interim ATO
Residual risk is acceptable short-term. The system may operate under specific conditions with a defined remediation timeline for open POA&M items. Not a permanent state.
The ISSO prepares the authorization package. The ISSM reviews it. The Authorizing Official signs it. The AO is accepting organizational risk on behalf of leadership, not rubber-stamping a technical team’s work. An AO who does not understand what they are signing is a governance failure, not a paperwork problem.
Monitor: Keeping the Authorization Current
Authorization is not a one-time event. The HR system will change: new integrations, new data types, configuration updates, personnel changes. Monitor is the ongoing process of ensuring the controls documented in the SSP continue to work as described and that changes to the system do not invalidate the authorization.
- Regular review of audit logs for anomalies: failed logins, unusual access patterns, bulk data exports
- Quarterly access reviews to catch privilege creep and stale accounts
- Tracking POA&M items to closure and updating the AO when remediations are complete
- Assessing any system change against the existing control baseline: does adding a new integration change the attack surface or introduce a new data type that changes the categorization?
Not every change requires starting RMF over. A configuration update that does not change the system boundary or data types can be handled within Monitor. Adding a new module that processes financial data outside the existing scope might trigger a return to Categorize because the high water mark could change. The question is always whether the change affects what the system does with sensitive data, not just how it does it.
The Point
RMF is a decision-making process, not a checklist. Every step produces something: a categorization document, a tailored baseline, an SSP, a SAR, a POA&M, an ATO package. Those artifacts are how security decisions get made, communicated, and defended at the organizational level. Categorize honestly, select appropriately, implement completely, assess independently, authorize deliberately, and monitor continuously.
