Framework

NIST SP 800-37
Risk Management Framework on one operating record

NIST Special Publication 800-37 Revision 2 (December 2018) is the seven-step Risk Management Framework (RMF) federal agencies, FedRAMP cloud service providers, defence contractors, and regulated enterprises operate against. This page covers the seven steps (Prepare, Categorise, Select, Implement, Assess, Authorise, Monitor), the FIPS 199 impact categorisation, the named roles and artefacts (SSP, SAR, POA&M, ADD), how RMF sits next to NIST CSF 2.0, NIST SP 800-53, FedRAMP, and CMMC, the recurring failure modes, the audit evidence the framework expects, and how a workspace-driven approach turns RMF into a defensible operating record rather than a stack of disconnected documents.

Get Started Free

No credit card required. Free plan available forever.

NIST SP 800-37 Risk Management Framework (RMF) explained

NIST Special Publication 800-37 Revision 2 (December 2018), titled the Risk Management Framework for Information Systems and Organisations, is the seven-step framework federal agencies, FedRAMP cloud service providers, defence contractors, regulated enterprises, and any organisation operating under FISMA reads against to manage information system security and privacy risk. The framework expanded from six steps to seven in Revision 2 with the addition of the Prepare step at both the organisation and system level, and integrated privacy controls and supply chain risk management into the operating sequence.

For internal security teams, AppSec teams, GRC owners, vulnerability management functions, security architects, security engineering teams, and CISOs, RMF is the vocabulary that lets a security programme communicate consistently across federal procurement reviews, the FedRAMP authorisation, the CMMC certification, audit committees, and enterprise customer security questionnaires. Programmes already operating against NIST SP 800-53, NIST CSF 2.0, or ISO 27001 do not migrate to RMF; the framework reads as the federal-side operating sequence that places those control catalogues into a structured authorisation lifecycle.

The seven steps: Prepare, Categorise, Select, Implement, Assess, Authorise, Monitor

RMF Revision 2 organises the framework into seven sequential steps. The steps are sequential in dependency, not strictly in calendar time: continuous monitoring produces evidence the next reauthorisation reads against, so the framework operates as a cycle rather than as a one-off project. Each step has named tasks, named roles, named artefacts, and a specified output that the next step reads against.

Step 1: Prepare

Prepare the organisation and the information system to execute the rest of the framework. The Prepare step was added in Revision 2 (December 2018) and is the practice the framework now leans on for the cross-cutting governance work that earlier RMF revisions assumed but did not name. At the organisation level, Prepare identifies risk management roles, establishes risk management strategy, conducts organisation-wide risk assessment, defines authorisation boundaries and common controls, prioritises systems, and develops the continuous monitoring strategy. At the system level, Prepare identifies the mission and business owners, the system stakeholders, the asset boundaries, the system requirements, the enterprise architecture context, and the system-level risk assessment. Prepare has 18 tasks split between organisation-level (P-1 through P-7) and system-level (P-8 through P-18).

Step 2: Categorise

Categorise the information system and the information processed, stored, and transmitted based on impact analysis. The step reads against FIPS Publication 199 (Standards for Security Categorisation of Federal Information and Information Systems) for the categorisation method and NIST SP 800-60 for the information type catalogue. The output is a categorisation against confidentiality, integrity, and availability at low, moderate, or high impact, and the documented system description, the system boundary, and the security categorisation decision. The Categorise step is short on task count (3 tasks: C-1 through C-3) but high on downstream consequence: the categorisation drives the control baseline selected in the next step.

Step 3: Select

Select an initial set of baseline security controls for the system based on the categorisation, then tailor the baseline against the operating context. The baseline comes from NIST SP 800-53 Rev. 5 control catalogue. Tailoring covers scoping decisions (applying or removing controls based on the system context), parameterisation (filling in the implementation-specific parameters the catalogue leaves open), compensating controls (substitute controls where the named control cannot be implemented), supplemental controls (adding controls beyond the baseline where the risk assessment justifies), and the monitoring strategy that drives the continuous monitoring step. The Select step has 6 tasks (S-1 through S-6) and produces the System Security Plan (SSP) the rest of the framework writes to.

Step 4: Implement

Implement the controls specified in the System Security Plan, then document the implementation. The implementation work is the engineering and operating work the rest of the framework reads against: configuration baselines, identity and access controls, logging, encryption, vulnerability management, incident response, contingency planning, and the other 800-53 control families implemented per the SSP. The Implement step has 2 tasks (I-1 and I-2) but is the longest in calendar time: the implementation evidence per control is what the assessment in Step 5 reads against and what the authorisation in Step 6 commits to.

Step 5: Assess

Assess the security controls using appropriate assessment procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome. The Assess step uses NIST SP 800-53A as the assessment procedure catalogue. The assessor (an internal team, an independent assessor, or a third-party assessor depending on the system) reviews the SSP, runs the assessment procedures, and produces the Security Assessment Report (SAR) with the findings and the recommended remediation. The Assess step has 6 tasks (A-1 through A-6) and produces the SAR plus the Plan of Action and Milestones (POA&M) that captures the remediation commitments.

Step 6: Authorise

The Authorising Official reviews the SSP, the SAR, the POA&M, and any supplementary evidence, makes the authorisation decision (Authorisation to Operate, Authorisation to Use, Common Control Authorisation, or Denial of Authorisation), and signs the authorisation memorandum. Authorise is the explicit risk acceptance the rest of the framework supports. The AO accepts the residual risk in writing on behalf of the organisation. The Authorise step has 5 tasks (R-1 through R-5) and produces the Authorisation Decision Document (ADD) and the Authorisation Package (the SSP, the SAR, the POA&M, and the supporting evidence consolidated for the AO).

Step 7: Monitor

Monitor the security controls in the system on an ongoing basis. The Monitor step is the continuous evidence layer of the framework: configuration changes, vulnerability scanning, audit log review, security control assessment on a defined cadence, plan-of-action-and-milestones tracking, ongoing risk determination, and authorisation maintenance. Monitor reads the same control set the SSP defines and the SAR assessed against, but on a cadence rather than as a one-off event. The Monitor step has 7 tasks (M-1 through M-7) and produces the continuous monitoring evidence the next reauthorisation reads against.

FIPS 199 categorisation: low, moderate, high

The Categorise step reads against FIPS Publication 199 for the impact-level determination. The categorisation drives the control baseline selected in Step 3, the assessment depth in Step 5, the AO seniority in Step 6, and the continuous monitoring cadence in Step 7. The decision applies to confidentiality, integrity, and availability independently; the high-water-mark across the three drives the overall system categorisation.

Low impact: the loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organisational operations, organisational assets, or individuals. Limited adverse effect means the loss might cause a degradation in mission capability but the organisation is still able to perform its primary functions, result in minor damage to organisational assets, result in minor financial loss, or result in minor harm to individuals.

Moderate impact: the loss could be expected to have a serious adverse effect. Serious adverse effect means the loss might cause a significant degradation in mission capability such that the organisation is able to perform its primary functions but the effectiveness is significantly reduced, result in significant damage to organisational assets, result in significant financial loss, or result in significant harm to individuals that does not involve loss of life or serious life-threatening injuries.

High impact: the loss could be expected to have a severe or catastrophic adverse effect. Severe or catastrophic adverse effect means the loss might cause a severe degradation in or loss of mission capability such that the organisation is not able to perform one or more of its primary functions, result in major damage to organisational assets, result in major financial loss, or result in severe or catastrophic harm to individuals involving loss of life or serious life-threatening injuries.

Named roles and artefacts the framework expects

RMF names roles and artefacts with specific responsibilities. The named roles give the framework an accountability layer the assessment, the authorisation, and the continuous monitoring read against. Programmes that adopt RMF without designating the named roles end up with unsigned artefacts and an assessment trail that does not name the responsible parties.

  • Risk Executive (function): the senior-leadership role that holds organisation-wide risk management responsibility and ensures the risk decisions across systems are consistent with the organisation risk tolerance.
  • Authorising Official (AO): the senior official with the authority to formally assume responsibility for operating an information system at an acceptable level of risk. The AO signs the authorisation decision.
  • Senior Agency Information Security Officer (SAISO): the official responsible for carrying out the CIO responsibilities for information security under FISMA.
  • Information System Owner: the official responsible for the procurement, development, integration, modification, operation, maintenance, and disposal of the system.
  • Information Owner / Steward: the official with statutory, management, or operational authority for specified information and the responsibility for establishing the controls for its generation, classification, collection, processing, dissemination, and disposal.
  • Information System Security Officer (ISSO): the official responsible to the AO, the CIO, or the System Owner for ensuring the appropriate operational security posture is maintained for the system.
  • Control Assessor: the individual, group, or organisation responsible for conducting the comprehensive assessment of the management, operational, and technical security controls.
  • Security Control Assessor (SCA): synonymous with Control Assessor in many federal programmes. The SCA produces the Security Assessment Report.
  • Common Control Provider: the organisation responsible for the development, implementation, assessment, and monitoring of common controls inherited by multiple systems.
  • Plan of Action and Milestones (POA&M): the artefact that captures the remediation commitments arising from the assessment, with the assigned owner, the required resources, the milestones, the scheduled completion date, and the status.
  • System Security Plan (SSP): the artefact that describes the system, the system boundary, the security categorisation, the selected controls, the tailoring decisions, the parameters, and the implementation evidence per control.
  • Security Assessment Report (SAR): the artefact that documents the assessor findings, the recommendations, and the residual risk assessment after assessment of the implemented controls.
  • Authorisation Decision Document (ADD): the artefact that captures the AO authorisation decision, the terms and conditions of authorisation, the authorisation termination date, and the supporting basis.

Where RMF sits next to NIST CSF 2.0, NIST 800-53, FedRAMP, and CMMC

RMF is the operating sequence that places the NIST SP 800-53 control catalogue into a structured authorisation lifecycle. The two are paired: 800-37 is the process framework, 800-53 is the control catalogue. NIST CSF 2.0 is the outcomes-oriented framework boards and senior leaders read against; CSF describes what to achieve, RMF describes how a federal system authorises and operates against the controls that achieve it. FedRAMP is the cloud-service-provider authorisation programme that operates RMF with FedRAMP-specific baselines, the FedRAMP Program Management Office, and the JAB or Agency authorisation paths. CMMC is the Department of Defense certification programme for defence contractors that reads CUI-handling controls from NIST SP 800-171 (which derives from 800-53) and assesses contractor maturity at the named CMMC levels. A regulated programme that operates under FISMA, sells to federal civilian agencies, sells to the Department of Defense, or provides cloud services to the federal government typically reads multiple of these frameworks together; RMF is the operating sequence the others place into.

Recurring failure modes RMF programmes hit

Programmes that struggle with RMF typically hit a small set of recurring failure modes. Naming the failure modes upfront lets the programme design controls to avoid them rather than discovering them during the AO defence.

Treating the SSP as a Word document. Programmes that hold the SSP as a static document outside the operating record discover at assessment time that the implementation has drifted from the SSP. The SSP is meant to read live against the operating evidence: the configuration baselines, the access reviews, the vulnerability scans, the patch records, the activity log. An SSP that does not reconcile with the operating record is an SSP the AO is signing against a snapshot rather than against the actual posture.

Treating Categorise as a paperwork exercise. The FIPS 199 categorisation drives the entire downstream framework: the control baseline, the assessment scope, the AO responsibilities, the continuous monitoring cadence, and the reauthorisation period. Programmes that categorise quickly to get past Step 2 carry the misalignment through every subsequent step. The categorisation deserves the same diligence as the Authorise decision because it shapes the work the rest of the framework asks for.

Skipping the tailoring rationale. NIST SP 800-53B provides the moderate, low, and high baselines. The baseline is a starting point, not the final selection. Programmes that adopt the baseline without documenting the tailoring decisions (scoping rationale, parameterisation choices, compensating controls, supplemental controls) carry an undefended posture into the assessment because the assessor cannot read why the controls look the way they do.

Running Implement and Assess in parallel rather than in sequence. Some programmes start the assessment work before the implementation work has settled, on the assumption that the parallel execution shortens the calendar. The cost is that the assessor finds implementation gaps that the implementation team is still fixing, the SAR carries findings that are already in remediation by the time the SAR is signed, and the POA&M starts the lifecycle with stale entries. The framework expects Implement to complete before Assess starts; programmes that compress the sequence rebuild the assessment trail.

Treating the Authorise step as a formality. The AO authorisation decision is the explicit risk acceptance. AOs who sign without reading the SSP, the SAR, the POA&M, and the supporting evidence carry personal accountability for residual risk they did not review. The framework expects the AO to actively consider the authorisation decision, document the basis, and tie the authorisation to the conditions under which it is valid. Programmes that treat authorisation as a rubber stamp rebuild the AO defence at the next incident or audit.

Underbuilding the Monitor step. The framework expects continuous monitoring as the operating evidence between assessments. Programmes that implement controls, get the authorisation, and then go quiet until the reauthorisation cycle carry stale evidence into the next assessment. Configuration drift, vulnerability backlog growth, exception register growth, and audit-log gaps all accumulate during the silent period. Continuous monitoring is the framework practice that prevents the reauthorisation from becoming a six-month reconstruction project.

Holding the artefact set across tools that do not reconcile. The SSP in one tool, the SAR in another, the POA&M in a third, the configuration baselines in a fourth, the vulnerability scans in a fifth, and the activity log in a sixth makes the assessment a reconciliation exercise rather than a posture review. Programmes that hold the RMF artefact set on a single operating record produce assessments that read the live state; programmes that scatter the artefacts produce assessments that read the latest snapshot from each tool.

Evidence the framework expects to see

A defensible RMF programme produces a stable evidence set across the seven steps. The artefact set is the authorisation package the AO signs against and the same evidence the continuous monitoring, the reauthorisation, and the parallel framework reads (ISO 27001 audit, SOC 2 examination, FedRAMP assessment, CMMC assessment) consume.

  • System Security Plan (SSP) with the system description, the system boundary, the FIPS 199 categorisation, the selected controls with tailoring rationale, the parameters, the implementation evidence reference per control, and the ISSO and SO signatures
  • Security Assessment Report (SAR) with the assessment procedures applied, the findings per control, the severity per finding, the recommended remediation, and the assessor signature
  • Plan of Action and Milestones (POA&M) with the per-finding owner, the required resources, the milestones, the scheduled completion date, the status, and the per-update history
  • Authorisation Decision Document (ADD) with the AO authorisation decision, the terms and conditions, the authorisation termination date, the residual risk assessment, and the AO signature
  • Continuous Monitoring Strategy and the per-cycle monitoring evidence: configuration change reviews, vulnerability scan reports, audit log review records, control reassessment outputs on the defined cadence
  • Configuration baseline evidence per system component, with the change control record, the configuration deviation tracking, and the configuration audit results
  • Vulnerability management evidence covering scan execution records, finding triage, severity calibration, remediation SLAs, exception register entries, and retest evidence per remediated finding
  • Access review evidence per access-control review cycle, with the user inventory, the role mapping, the access grant rationale, the access removal records, and the privileged-account inventory
  • Incident response evidence covering the IR plan, the tabletop exercise records, the actual incident records, the lessons-learned outputs, and the IR plan revision history
  • Contingency planning evidence covering the contingency plan, the contingency test records, the alternate site evidence, and the backup execution record
  • Risk assessment artefacts per the Prepare and Categorise steps, with the threat sources, the threat events, the vulnerabilities, the likelihood, the impact, and the resulting risk determinations
  • Training and awareness evidence per the PO-aligned role definitions, with the training delivery record, the per-individual completion record, and the per-role training requirement

How RMF reads across security functions

RMF is a cross-functional framework. The same operating record reads differently depending on the function that holds the work. Programmes that run RMF as a GRC exercise alone lose the engineering depth the framework expects; programmes that run it as an engineering exercise alone lose the governance depth. The named functions below own different parts of the same artefact set.

Internal security teams

Run the RMF programme on the engagement record. Hold the SSP, the SAR, the POA&M, the ADD, and the continuous monitoring evidence on one workspace so the assessment cycle reads the live operating posture rather than reconstructing it from scattered tools. Carry the Prepare step output (the risk management roles, the risk strategy, the authorisation boundary, the common controls inventory) as workspace artefacts that the rest of the framework reads against.

GRC and compliance teams

Read RMF as the federal-grade vocabulary for the same posture the ISO 27001, SOC 2, and PCI DSS reads consume. Run the Step 3 control selection against a workspace where the 800-53 baseline maps to the parallel framework controls so the tailoring decisions, the parameterisation, and the compensating controls evidence consume cleanly across the SSP, the ISO 27001 Statement of Applicability, and the SOC 2 description of the system.

CISOs and security leaders

Carry the RMF programme accountability at the operating layer. Track the per-system authorisation status, the POA&M aging, the continuous monitoring cadence adherence, the reauthorisation timeline, and the AO defence record. Read RMF as the federal practice catalogue behind the FedRAMP authorisation, the CMMC certification, and the regulated-buyer security questionnaire reads, not as an engineering check-list.

Vulnerability management teams

Own the RA-5 (vulnerability monitoring) and SI-2 (flaw remediation) work on the operating record. Run scanner ingestion, severity calibration, remediation SLA enforcement, exception register governance, and retest evidence on the findings record so the POA&M entries the AO reads carry the live remediation trail rather than a snapshot from the assessment week.

Security architects

Carry the Prepare step (P-11 system requirements, P-12 enterprise architecture context, P-13 boundary determination) and the Select step tailoring rationale as architecture outputs. Document the authorisation boundary, the data-flow context, the trust boundaries, and the inherited common controls so the SSP reads the architecture decision rather than describing it after the fact.

AppSec teams and security engineering teams

Own the SA-11 (developer security testing), SI-7 (software, firmware, and information integrity), and CM-3 (configuration change control) evidence at the operating layer. Run code scanning against connected repositories, hold the secure-coding standard and the enforcement record, and pair each change with the assessment evidence so the Step 4 implementation reads the live engineering posture.

Running RMF on SecPortal

SecPortal is built around the operating record an RMF programme reads against: the engagement is the per-system authorisation cycle, the findings record carries the assessment and the POA&M, the documents area carries the SSP, the SAR, and the ADD, and the activity log carries the audit trail every named control reads against. The platform alignment below maps the verified product capabilities to the RMF steps and artefacts so the framework is held on one operating record rather than reconstructed at AO sign-off.

  • Engagement management as the workspace anchor for the RMF programme, with the per-system authorisation cycle, the assessment scope, the AO sign-off, and the reauthorisation cadence tracked as engagements that produce the artefact set as a side effect rather than as a parallel project
  • Findings management with CVSS 3.1 calibration so the Step 5 assessment findings, the POA&M entries, and the continuous monitoring vulnerabilities all read the same severity vocabulary and the remediation SLA is enforceable
  • Compliance tracking across NIST SP 800-53, NIST CSF 2.0, NIST SSDF, FedRAMP, CMMC, ISO 27001, SOC 2, PCI DSS, and the additional framework catalogues, so the RMF control selection (Step 3) reads against the same record the parallel framework reads consume
  • Code scanning via Semgrep against connected repositories so the SA-11 developer security testing evidence and the SI-2 flaw remediation evidence accumulate as scan execution records archived per system
  • Authenticated scanning and domain scanning so the RA-5 vulnerability monitoring control, the SI-4 information system monitoring control, and the SC-7 boundary protection assessment all have the scan-side evidence on the operating record
  • Document management for the SSP, the SAR, the POA&M, the ADD, the continuous monitoring records, the configuration baselines, the contingency plan, and the IR plan, so the authorisation package lives on the record rather than across a folder hierarchy that drifts from the operating reality
  • Activity log with CSV export so every state change to a finding, an engagement, a document, a user role, or a credential is reproducible from one source, which is the audit trail AU-2, AU-3, AU-6, and AU-12 controls read against
  • Repository connections via GitHub, GitLab, and Bitbucket OAuth so the SA-15 development process control, the CM-3 configuration change control, and the SA-11 developer security testing evidence read against the same source-control state
  • Multi-factor authentication for workspace access so the IA-2 identification and authentication control reads against the operating posture rather than against a policy statement
  • Team management with RBAC so the AC-2 account management, the AC-6 least privilege, and the PS-2 position risk designation controls have the per-role evidence the assessment expects
  • AI report generation that turns the engagement record into the AO-readable authorisation package narrative, the continuous monitoring summary, and the reauthorisation read the leadership consumes alongside the underlying artefacts
  • Retesting workflows paired to the original finding, so the POA&M remediation evidence carries the verify-after-fix record the assessor reads against

Related reading on SecPortal

Key control areas

SecPortal helps you track and manage compliance across these domains.

Step 1: Prepare

Prepare the organisation and the system to execute the rest of the framework. Added in Revision 2 (December 2018), the Prepare step covers organisation-level work (risk management roles, risk strategy, authorisation boundary, common controls, continuous monitoring strategy) and system-level work (mission and business owners, asset boundaries, system requirements, enterprise architecture context, system-level risk assessment). Prepare has 18 tasks: P-1 through P-7 at the organisation level and P-8 through P-18 at the system level. The Prepare outputs are the foundation the remaining steps read against.

Step 2: Categorise

Categorise the system and the information processed, stored, and transmitted based on impact analysis. The step reads against FIPS Publication 199 for the categorisation method and NIST SP 800-60 for the information type catalogue. The output is a categorisation across confidentiality, integrity, and availability at low, moderate, or high impact, plus the documented system description, the system boundary, and the categorisation rationale. Categorise has 3 tasks (C-1 through C-3); the categorisation drives the baseline selected in Step 3, the assessment depth in Step 5, the AO seniority in Step 6, and the continuous monitoring cadence in Step 7.

Step 3: Select

Select an initial set of baseline controls from the NIST SP 800-53 Rev. 5 catalogue and tailor the baseline against the operating context. Tailoring covers scoping (applying or removing controls based on context), parameterisation (filling in implementation parameters), compensating controls (substitutes where the named control cannot be implemented), supplemental controls (additions beyond the baseline), and the monitoring strategy that drives Step 7. Select has 6 tasks (S-1 through S-6) and produces the System Security Plan (SSP) that the rest of the framework writes to.

Step 4: Implement

Implement the controls specified in the SSP and document the implementation. The implementation work is the engineering and operating work: configuration baselines, identity and access controls, logging, encryption, vulnerability management, incident response, contingency planning, and the other 800-53 control families implemented per the SSP. Implement has 2 tasks (I-1 and I-2) but is the longest in calendar time. The implementation evidence per control is what the assessment in Step 5 reads against and what the authorisation in Step 6 commits to.

Step 5: Assess

Assess the controls using NIST SP 800-53A assessment procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome. The assessor (internal team, independent assessor, or third-party assessor) reviews the SSP, runs the assessment procedures, and produces the Security Assessment Report (SAR) with the findings and the recommended remediation. Assess has 6 tasks (A-1 through A-6) and produces the SAR plus the initial Plan of Action and Milestones (POA&M) capturing the remediation commitments.

Step 6: Authorise

The Authorising Official reviews the SSP, the SAR, the POA&M, and any supplementary evidence, makes the authorisation decision (Authorisation to Operate, Authorisation to Use, Common Control Authorisation, or Denial of Authorisation), and signs the authorisation memorandum. Authorise is the explicit risk acceptance the rest of the framework supports; the AO accepts residual risk in writing on behalf of the organisation. Authorise has 5 tasks (R-1 through R-5) and produces the Authorisation Decision Document (ADD) and the Authorisation Package (the SSP, the SAR, the POA&M, and the supporting evidence consolidated for the AO).

Step 7: Monitor

Monitor the controls in the system on an ongoing basis. Monitor is the continuous evidence layer of the framework: configuration change reviews, vulnerability scanning, audit log review, control reassessment on a defined cadence, POA&M tracking, ongoing risk determination, and authorisation maintenance. Monitor reads the same control set the SSP defines and the SAR assessed against, but on a cadence rather than as a one-off event. Monitor has 7 tasks (M-1 through M-7) and produces the continuous monitoring evidence the next reauthorisation reads against. Programmes that underbuild Monitor carry stale evidence into the reauthorisation cycle.

FIPS 199 categorisation: low, moderate, high impact

The FIPS Publication 199 categorisation applies to confidentiality, integrity, and availability independently; the high-water-mark across the three drives the overall system categorisation. Low impact means a limited adverse effect on operations, assets, or individuals. Moderate impact means a serious adverse effect with significant degradation in mission capability, significant damage, significant financial loss, or significant harm. High impact means a severe or catastrophic adverse effect with severe degradation in or loss of mission capability, major damage, major financial loss, or severe or catastrophic harm including loss of life. The decision drives the control baseline selected in Step 3, the assessment depth, the AO seniority, and the continuous monitoring cadence.

Named roles: AO, ISSO, System Owner, Control Assessor, Risk Executive

RMF names roles with specific responsibilities. The Authorising Official (AO) signs the authorisation decision and accepts residual risk. The Information System Security Officer (ISSO) maintains the security posture on behalf of the AO, CIO, and System Owner. The System Owner is responsible for the procurement, development, integration, modification, operation, maintenance, and disposal of the system. The Control Assessor conducts the comprehensive assessment of the management, operational, and technical controls. The Risk Executive (function) holds organisation-wide risk management responsibility. The Common Control Provider develops and maintains the controls inherited by multiple systems. The Information Owner has statutory, management, or operational authority for specified information.

Named artefacts: SSP, SAR, POA&M, ADD, continuous monitoring evidence

The System Security Plan (SSP) describes the system, the boundary, the FIPS 199 categorisation, the selected controls, the tailoring decisions, the parameters, and the implementation evidence reference per control. The Security Assessment Report (SAR) documents the assessor findings, the recommendations, and the residual risk assessment. The Plan of Action and Milestones (POA&M) captures the remediation commitments arising from the SAR with the assigned owner, the required resources, the milestones, the scheduled completion date, and the status. The Authorisation Decision Document (ADD) captures the AO authorisation decision, the terms and conditions, the authorisation termination date, and the supporting basis. The continuous monitoring evidence is the running record produced through Step 7 that the next reauthorisation reads against.

RMF and NIST SP 800-53, NIST CSF 2.0, FedRAMP, and CMMC

RMF is the operating sequence; NIST SP 800-53 is the control catalogue. The two are paired: 800-37 is the process framework, 800-53 is the control set. NIST CSF 2.0 is the outcomes-oriented framework boards and senior leaders read against; CSF describes what to achieve, RMF describes how a federal system authorises and operates against the controls that achieve it. FedRAMP is the cloud-service-provider authorisation programme that operates RMF with FedRAMP baselines and the JAB or Agency authorisation paths. CMMC is the Department of Defense certification programme that reads CUI-handling controls from NIST SP 800-171 and assesses contractor maturity at the named CMMC levels. A regulated programme typically reads multiple of these frameworks together; RMF is the operating sequence the others place into.

Audit evidence the framework expects

A defensible RMF programme produces a stable evidence set: the SSP with the categorisation, the selected controls, the tailoring, the parameters, and the implementation evidence per control; the SAR with the assessment procedures applied, the findings, and the assessor signature; the POA&M with the per-finding owner, milestones, completion dates, and per-update history; the ADD with the AO authorisation, terms, conditions, and signature; the continuous monitoring strategy and per-cycle monitoring evidence; configuration baseline evidence per system component; vulnerability management evidence covering scan execution, finding triage, severity calibration, remediation SLAs, exception register entries, and retest evidence; access review evidence per cycle; incident response evidence; contingency planning evidence; risk assessment artefacts; and training and awareness evidence. The same evidence set reads cleanly under FedRAMP, CMMC, ISO 27001, SOC 2, NIST CSF 2.0, and parallel framework reads.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Compliance tracking without a full GRC platform

Find vulnerabilities before they ship

Test web apps behind the login

Document management for every security engagement

Every action recorded across the workspace

Multi-factor authentication on every workspace

Collaborate across your entire team

AI-powered reports in seconds, not days

Verify fixes and track reopens on the same finding record

Run a defensible RMF programme on one operating record

Hold the SSP, the SAR, the POA&M, the ADD, and the continuous monitoring evidence on one workspace so the AO sign-off reads the live operating posture, then carry the same record into FedRAMP, CMMC, ISO 27001, SOC 2, and procurement reads without rebuilding the artefact set. Start free.

Get Started Free

No credit card required. Free plan available forever.