NIST SP 800-37 – Tutorial (about 60 minutes)

NIST Special Publication 800-37 describes the Risk Management Framework (RMF): a repeatable, seven-step process that an organisation follows to decide which security and privacy safeguards a system needs, to put them in place, to check that they work, to have a senior official formally accept the remaining risk, and to keep watching that risk while the system runs. US federal agencies must use it, defence and cloud programmes are built on it, and many contractors, universities and private firms follow it voluntarily. After this tutorial you will be able to explain each step and its outputs, name the roles involved, follow how an authorisation decision is reached and maintained, and apply the process to a realistic system.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, published by the US National Institute of Standards and Technology (NIST) as a final publication in December 2018. It superseded Revision 1 (2010, with a 2014 errata update). The NIST Computer Security Resource Center lists Revision 2 as final and current; it has not been withdrawn, and no Revision 3 draft or comment period has been announced on the publication page or the RMF project news page. Since 2018 NIST has supported the RMF with companion material rather than a new revision, for example the RMF Quick Start Guides and SP 1314, the RMF Small Enterprise Quick Start Guide (July 2024), and the controls it relies on have moved on to SP 800-53 Revision 5 (latest release 5.2.0, August 2025). This course teaches Revision 2. Verified 2026-10-29 on csrc.nist.gov.

Who this is for: security and cloud engineers, system owners, project and programme managers, assessors and auditors, privacy staff and compliance or risk analysts who must take a system through the RMF for the first time, for example because the customer is a US agency, because the system needs an "ATO", or because leadership chose the RMF as the organisation's way of managing security risk.

Prerequisites: none. A rough idea of what a security control is (a safeguard such as multi-factor sign-in, an encrypted backup or a written incident procedure) helps. Every other term is explained when it first appears.

By the end of this tutorial:

• You will be able to explain why the RMF exists, whom it binds and what changed in Revision 2.
• You will be able to define the core vocabulary: authorisation boundary, categorisation, common and hybrid controls, authorisation package, POA&M and ongoing authorisation.
• You will be able to name the seven steps in order and state the main outputs of each one.
• You will be able to describe who does what, from the head of the organisation to the system owner, the control assessor and the authorising official.
• You will be able to explain how controls are assessed, what goes into an authorisation package and the four kinds of authorisation decision.
• You will be able to walk a realistic system through the whole framework, including what happens after go-live.
• You will be able to place SP 800-37 next to SP 800-53, FIPS 199, the NIST Cybersecurity Framework, ISO/IEC 27001 and FedRAMP.

Lesson 1 – Origins, purpose and scope

The problem the RMF solves

Every organisation that runs computer systems makes risk decisions, whether it admits it or not. Someone decides that a new web application may go live with a known weakness because the deadline matters more; someone else decides that a legacy server can stay online for another year. When these decisions are made informally, nobody can later say who accepted which risk, on what evidence, or whether the facts have since changed. Large organisations end up with hundreds of systems, each protected to a different and unknown standard.

The US federal government addressed this problem through law. The Federal Information Security Management Act of 2002, modernised in 2014 as the Federal Information Security Modernization Act (both known as FISMA), makes each agency head responsible for protecting the agency's information and systems and gives NIST the job of writing the standards and guidelines agencies use. The Office of Management and Budget (OMB), which sets federal management policy, then requires agencies to follow that guidance; its Circular A-130, Managing Information as a Strategic Resource, directs agencies to manage security and privacy risk using the NIST Risk Management Framework.

SP 800-37 is the document that describes that framework. It does not list safeguards itself (that is the job of SP 800-53, the control catalogue). Instead, it describes the process: the sequence of tasks, the people responsible, the documents produced and the decision points that turn a pile of controls into a defensible, accountable risk decision.

From certification and accreditation to risk management

The first edition, published in 2004, was called a guide for the security certification and accreditation (C&A) of federal systems. C&A was largely a paperwork event: a system was "certified" by a technical review and "accredited" by a manager, usually for three years, after which the cycle repeated. Systems often drifted out of their accredited state between reviews, and the large document packages were expensive to produce and rarely read.

Revision 1 (2010) replaced C&A with the Risk Management Framework. It introduced a six-step life cycle (Categorize, Select, Implement, Assess, Authorize, Monitor), emphasised building security into systems from the start, and put continuous monitoring at the centre so that the authorisation decision could stay current. The words "certification" and "accreditation" were retired in favour of "assessment" and "authorisation".

Revision 2 (December 2018) kept the six steps and added a seventh, Prepare, at the front. The authors stated seven objectives for the update, which in summary were:

• link risk decisions made by senior leadership more closely with the work done at system and operational level;
• make the preparatory work (roles, strategy, common controls, priorities) a formal step, so that individual system owners do not reinvent it each time;
• show how the NIST Cybersecurity Framework can be aligned with and implemented through the RMF;
• integrate privacy risk management into the same process as security risk management;
• connect RMF tasks with the systems security engineering processes of SP 800-160 Volume 1, to encourage trustworthy systems by design;
• bring supply chain risk management (counterfeits, tampering, malicious code inserted by suppliers, poor development practices) into the framework;
• allow an organisation to build its own control set, as an alternative to starting from a predefined baseline, using the consolidated catalogue of SP 800-53 Revision 5.

Scope and applicability

The RMF applies to any kind of system: general-purpose IT, cloud services, mobile and Internet of Things devices, industrial control and other operational technology, weapons systems and high-performance computing. It also applies whatever the development approach, including waterfall, Agile and DevOps. For federal agencies and for systems operated on their behalf it is mandatory. State, local and tribal governments and private organisations are encouraged to use it voluntarily, and many do because it is free, detailed and well understood by US customers.

One boundary is worth remembering. Contractors and other external providers can perform every RMF step for a federal system except the Authorize step, because accepting risk on behalf of the government is an inherently governmental responsibility. A cloud company can prepare, categorise, implement and assess; only a federal official can say "we accept this risk".

Lesson 2 – Key concepts and vocabulary

The RMF has its own language. Most confusion in real projects comes from people using these words loosely, so learn them precisely.

• Risk – the extent to which an organisation is threatened by a possible event, combining how likely the event is with how much harm it would cause. The RMF manages security risk and privacy risk (risk to individuals from the processing of their personal data).
• Information system – a set of resources (hardware, software, data, people, procedures) organised to collect, process, store, transmit or dispose of information. In RMF terms "the system" is whatever falls inside one authorisation boundary.
• Authorisation boundary – the line that defines everything a single authorising official is accountable for. Drawing it too wide makes assessment unmanageable; drawing it too narrow leaves components with nobody responsible for them.
• Environment of operation – the physical surroundings and organisational setting in which the system runs, including the facilities and supporting services it depends on.
• Security categorisation – the process of rating the potential impact (low, moderate or high) on the organisation if the confidentiality, integrity or availability of the system's information were lost. It follows FIPS 199, with SP 800-60 helping to map information types to impact levels.
• Control – a safeguard or countermeasure, technical, operational or managerial, prescribed to meet security and privacy requirements. RMF controls come from the SP 800-53 catalogue.
• Control baseline – a predefined starting set of controls for a given impact level (published in SP 800-53B), or an organisation-tailored set developed during Prepare.
• Tailoring – adjusting a baseline to the specific system: removing controls that do not apply, adding controls the risk assessment shows are needed, filling in organisation-defined values and recording compensating alternatives.
• Common control – a safeguard implemented once and inherited by many systems, such as a data-centre physical security programme or an enterprise identity service. The party that provides it is the common control provider.
• Hybrid control – a control that is partly inherited and partly implemented by the system itself, for example a central logging service (inherited) plus system-specific decisions about which events to log (local).
• Security plan and privacy plan – the documents that describe the system, its boundary and how each selected control is or will be implemented. They may be combined into one document.
• Control assessment – testing and evaluating controls to determine whether they are implemented correctly, operating as intended and producing the desired outcome. The results go into an assessment report.
• Plan of action and milestones (POA&M) – the tracking document that lists each open weakness, the planned fix, the resources needed and target dates.
• Authorising official (AO) – the senior official with the authority and budget responsibility to formally accept the risk of operating a system or providing common controls. Accountability stays with this person.
• Authorisation package – the evidence given to the AO: an executive summary, the security and privacy plans, the assessment reports and the POA&M.
• Authorisation to operate (ATO) – the AO's decision that the risk of running the system is acceptable, normally with terms and conditions.
• Continuous monitoring – ongoing awareness of threats, vulnerabilities and control effectiveness, described in detail in SP 800-137 (information security continuous monitoring, ISCM).
• Ongoing authorisation – a mode in which the AO keeps re-deciding risk acceptance at agreed intervals or after events, using monitoring data instead of a fixed expiry date.
• Risk executive (function) – an individual or group that gives an organisation-wide view of risk so that system-level decisions stay consistent with the organisation's risk strategy and tolerance.
• High value asset (HVA) – information or a system so important to the organisation that its loss would have serious consequences; Revision 2 asks organisations to identify and prioritise these.

Three levels of risk management

The RMF sits inside a broader organisation-wide model described in SP 800-39. Risk is managed at three levels. Level 1, the organisation, sets governance, the risk management strategy and risk tolerance. Level 2, mission and business processes, decides how the organisation's work is done, which information it relies on and how it is protected through enterprise architecture. Level 3, the information system, is where controls are actually implemented and assessed. Strategy and constraints flow downwards; monitoring results, incidents and lessons flow upwards. The Prepare step exists largely to make that two-way flow real, so that a system owner at Level 3 inherits clear priorities and reusable controls instead of guessing.

Security and privacy: separate but connected

Revision 2 integrates privacy without merging it into security. Security programmes protect information in general against unauthorised access, change or loss. Privacy programmes protect individuals against problems that arise from processing their personal data, including problems caused by authorised processing, such as collecting more than needed or using data for an unexpected purpose. The two overlap where a security breach exposes personal data, which is why the RMF asks the security and privacy roles to collaborate at every step while each keeps its own responsibilities and, where needed, its own plan and assessment report.

Lesson 3 – Structure of the publication and the seven steps

How the document is organised

SP 800-37 Revision 2 has three chapters and eight appendices. Chapter One introduces purpose, applicability and audience. Chapter Two explains the fundamentals: organisation-wide risk management, the steps and structure of the framework, how security and privacy fit together, how a system and its elements are viewed, authorisation boundaries, requirements and controls, security and privacy posture, and supply chain risk management. Chapter Three is the core: one section per step, each containing the step's purpose, a table of outcomes and then the individual tasks.

The appendices provide references (A), a glossary (B), acronyms (C), roles and responsibilities (D), a summary table of all tasks with their primary and supporting roles (E), detailed guidance on system and common control authorisations (F), authorisation boundary considerations (G) and system life cycle considerations (H). Appendix E is the most useful single reference for a newcomer, because it shows who is responsible for every task.

Anatomy of a task

Every task has an identifier and the same set of fields: a short task statement; potential inputs; expected outputs; the primary responsibility (the role that owns it); supporting roles; the phase of the system development life cycle in which it normally happens; a discussion that explains the intent; and references to other NIST documents. Reading the expected outputs is the fastest way to understand what an assessor or AO will later ask to see.

The seven steps and their task identifiers

Task identifiers start with a letter for the step. Note that the Authorize step uses R, because A is taken by Assess.

Step	Purpose in plain words	Tasks
Prepare	Get the organisation and the system ready: roles, strategy, risk assessment, common controls, priorities, boundary, requirements.	P-1 to P-7 at organisation level; P-8 to P-18 at system level
Categorize	Describe the system and rate the impact of losing confidentiality, integrity or availability of its information.	C-1 to C-3
Select	Choose, tailor and allocate controls; document them in the plans; plan monitoring; approve the plans.	S-1 to S-6
Implement	Put the controls in place and record how they were actually implemented.	I-1 to I-2
Assess	Choose assessors, plan and run the assessment, report findings, fix what can be fixed, open a POA&M.	A-1 to A-6
Authorize	Assemble the package, determine and respond to risk, make and report the decision.	R-1 to R-5
Monitor	Track changes, keep assessing, respond, update documents, report posture, keep the authorisation current, retire the system safely.	M-1 to M-7

Sequence and flexibility

The steps are listed in order, and a system going through the RMF for the first time normally follows that order after Prepare. The publication is clear, though, that the steps after Prepare need not be strictly sequential. Agile teams may cycle between Select, Implement and Assess many times as features are added; a change discovered during Monitor may send the team back to Categorize or Select. The framework is also not a "one system, one pass" exercise: once Prepare work exists at organisation level, every new system reuses it.

Outcomes, not paperwork

Each step's outcomes table describes the state the organisation should reach, for example "common controls available for inheritance are identified, documented and published". Revision 2 deliberately frames the framework in terms of outcomes so that organisations can achieve them with tools and automation rather than with large documents. A security plan, for instance, can be a record in a governance tool or a set of machine-readable files rather than a word-processor file, provided it carries the required information.

Lesson 4 – How it works in practice

The people involved

Appendix D describes many roles. The ones a newcomer meets first are these:

• The head of agency (or chief executive) is ultimately accountable and appoints the people below.
• The senior accountable official for risk management and the risk executive (function) provide the organisation-wide view of risk and help keep decisions consistent.
• The chief information officer and the senior agency information security officer run the security programme; the senior agency official for privacy runs the privacy programme.
• The authorising official accepts risk. An AO designated representative may run day-to-day RMF activities on the AO's behalf, but may not make the authorisation decision or sign the decision document. In federal agencies the AO must be a government employee.
• The system owner is responsible for the system's procurement, development, operation and documentation, and prepares the authorisation package. The information owner or steward is responsible for particular information and its use.
• The system security officer and system privacy officer handle day-to-day security and privacy for the system; security and privacy architects and engineers design the protections into it.
• The common control provider implements, assesses and monitors inherited controls.
• The control assessor evaluates controls and reports results; the AO decides how independent the assessor must be.

Prepare

At organisation level (P-1 to P-7), leadership assigns RMF roles; sets a risk management strategy that states risk tolerance; runs or updates an organisation-wide risk assessment; publishes organisation-tailored control baselines or Cybersecurity Framework profiles; identifies common controls available for inheritance; prioritises systems that share the same impact level; and writes an organisation-wide continuous monitoring strategy. Done once and kept current, this work saves every system owner weeks of effort.

At system level (P-8 to P-18), the team identifies the missions and business processes the system supports, its stakeholders and the assets that need protection; determines the authorisation boundary; identifies the information types and the stages of each type's life cycle (creation, processing, storage, sharing, disposal); runs a system-level risk assessment; defines and prioritises security and privacy requirements; places the system in the enterprise architecture; allocates requirements to the system and its environment; and registers the system with the organisation's programme office.

Categorize

The team documents the system's characteristics (C-1), then categorises it (C-2). For each information type the team rates the potential impact on confidentiality, integrity and availability as low, moderate or high, using FIPS 199 definitions: limited, serious, or severe or catastrophic adverse effects. The overall system category is normally the highest value across all types and all three objectives, a rule known as the high-water mark. Finally the AO or designated representative reviews and approves the result (C-3). The category matters because it drives the baseline in the next step and shapes how much assurance the assessment needs.

Select

The team selects the controls (S-1), either by starting from a baseline that matches the category or by an organisation-generated approach that builds the control set directly from requirements. It then tailors them (S-2): scoping out what does not apply, setting organisation-defined values, adding controls the risk assessment calls for and documenting compensating controls. Each control is designated (S-3) as system-specific, hybrid or common, and allocated to the components that implement it. Everything is written into the security and privacy plans (S-4), a system-level monitoring strategy is developed (S-5), and the AO or designated representative reviews and approves the plans (S-6). Plan approval is an important checkpoint: it is the moment the AO agrees that the planned protection is adequate before money is spent building it.

Implement

The team implements the controls described in the plans (I-1), following best practice in systems security engineering, configuration management and secure development. Plans and reality rarely match exactly, so the team updates the plans to describe the "as implemented" state (I-2). An assessor who later finds that the documentation describes a different system from the one in production will rightly treat it as a finding.

Assess

The AO or designated representative selects an assessor or assessment team with the right expertise and the required degree of independence (A-1). The assessor writes an assessment plan, usually based on the procedures in SP 800-53A, and has it approved (A-2). The assessment itself (A-3) uses three methods: examining documents and configurations, interviewing people, and testing mechanisms and behaviour. Findings and recommendations go into the security and privacy assessment reports (A-4). The system owner may fix some weaknesses straight away, after which the assessor re-checks them (A-5). Everything left open goes into the POA&M (A-6).

Authorize

The system owner assembles the authorisation package and submits it (R-1). The AO, often advised by the senior accountable official for risk management or the risk executive (function), analyses the residual risk (R-2) and decides on a response for each significant risk, such as accepting it, mitigating it further, sharing or transferring it, or avoiding it (R-3). The AO then decides whether the overall risk is acceptable (R-4) and records the decision, its terms and conditions and either a termination date or the frequency of ongoing authorisation. The decision and any significant weaknesses are reported to organisational officials (R-5).

Monitor

Authorisation is not the finish line. The system owner and common control providers watch for changes to the system and its environment (M-1); assessors keep assessing controls at the frequency set in the monitoring strategy (M-2); the owner responds to what monitoring reveals (M-3); plans, assessment reports and POA&Ms are kept up to date (M-4); the security and privacy posture is reported to the AO and other officials (M-5); the AO reviews that information to keep the authorisation current (M-6); and when the system is retired, a disposal strategy ensures data are removed and connections closed (M-7). Good monitoring is largely automated: vulnerability scans, configuration compliance checks, log analysis and asset inventories feed dashboards that show control effectiveness in near real time.

The artefacts you will produce

Across the steps, a typical system ends up with: role assignments; a system description and boundary diagram; the categorisation record; security and privacy plans (with the tailored control set and implementation details); a continuous monitoring strategy; an assessment plan and assessment reports; a POA&M; the authorisation package with its executive summary; the authorisation decision document; and a stream of monitoring reports. Many organisations keep all of these in a governance, risk and compliance (GRC) tool so that updates in one place flow into the others.

Lesson 5 – Assessment, authorisation and compliance

There is no RMF certificate

Unlike ISO management-system standards, the RMF has no certification body and no certificate. The formal outcome is an authorisation decision made by an official of the organisation that owns the risk. A third-party assessor can test controls and write a report, but cannot "pass" a system. When a vendor says its product is "RMF certified", treat the claim with care: what may exist is an authorisation granted by a particular agency for a particular deployment, which another agency may or may not reuse.

How controls are assessed

Assessments follow SP 800-53A, which provides assessment procedures for each SP 800-53 control: objectives to determine, plus suggested objects and methods (examine, interview, test). The assessor chooses the depth and coverage of each method to match the assurance the AO needs; a high-impact system warrants deeper testing than a low-impact one. Assessments can be done by the system team itself (self-assessment) or by an independent assessor, meaning an individual or group able to conduct an impartial assessment. The AO decides the level of independence required, guided by law and policy. For privacy controls, OMB policy does not require independent assessment, though organisations may choose it.

Assessment is not a single event at the end of a project. Revision 2 encourages assessing controls as early as possible during development, reusing results from developmental testing and from other assessments, and automating repeatable checks so that the same evidence serves both the initial authorisation and continuous monitoring.

Kinds of authorisation decisions

• Authorisation to operate – the system may run, under stated terms and conditions. An AO can issue a short, restricted ATO when a system must be tested in its real environment before every control is in place (formerly called an interim authority to test).
• Common control authorisation – the equivalent decision for controls offered for inheritance by a common control provider.
• Authorisation to use – a customer organisation accepts the evidence in another organisation's existing package, for instance for a shared service or a cloud offering with a FedRAMP authorisation, and accepts the risk of using it with its own information. This is the RMF's main mechanism for reciprocity.
• Denial of authorisation – the risk is not acceptable; the system may not operate, or must stop operating if it already is.

Lifecycle of an authorisation

An initial authorisation is a complete review of all controls. Afterwards the organisation chooses between periodic reauthorisation (a point-in-time review, triggered by time or by an event) and ongoing authorisation. Ongoing authorisation is only possible when continuous monitoring is mature enough to give the AO current information; the AO then confirms risk acceptance at agreed intervals and the fixed termination date can be removed. Under ongoing authorisation, a reauthorisation still happens if an event pushes risk above the level the AO accepted, such as a major architecture change, a serious incident or a new threat. Significant changes and event-driven triggers should be defined in advance so that teams know when to involve the AO.

Variations on the basic model

Appendix F describes several variations. A type authorisation covers an archetype system deployed identically in many places, such as a standard workstation build; each site then issues an authorisation to use for its copy. A facility authorisation covers common controls provided by a defined environment, typically physical and environmental protections, so that systems located there can inherit them. A joint authorisation involves several AOs, from the same or different organisations, who share an interest in a system and jointly accept its risk; it stays valid only while they agree.

Who checks the checkers

For federal agencies, oversight comes from outside the RMF itself: FISMA requires agency reporting and annual independent evaluations of agency security programmes, and auditors review whether systems hold valid authorisations and whether POA&Ms are being worked. In practice, an "expired ATO" or a POA&M full of overdue items is one of the most common audit findings.

Programmes and credentials built on the RMF

Several programmes apply the RMF in a specific setting. FedRAMP applies it to cloud services used by federal agencies, so that one authorisation package can be reused by many agencies. The US Department of Defense applies it to defence systems through DoD Instruction 8510.01. For individuals, the security professional body ISC2 offers the Certified in Governance, Risk and Compliance (CGRC) credential, formerly called CAP, which is built around the RMF. These are credentials for people or decisions for systems; none of them certifies an organisation as "compliant with SP 800-37".

Lesson 6 – Worked example

To tie the steps together, follow a fictional organisation through one complete pass. The Northfield Benefits Agency (an invented US federal agency) is replacing a paper process with an online portal where citizens apply for a home-heating grant. The portal will run on a commercial cloud platform that already holds a FedRAMP authorisation. Applicants upload proof of income and identity, so the portal will hold personally identifiable information (PII).

Prepare

At organisation level, Northfield already has most Prepare outputs: the chief information officer is the AO for citizen-facing systems, the senior agency information security officer runs the security programme, and the risk management strategy states that the agency has low tolerance for exposure of citizens' financial data. The agency has published common controls for security awareness training, incident response, personnel screening and its enterprise identity service, plus an organisation-wide monitoring strategy.

At system level, the project team, led by the system owner from the grants division, identifies the business process (accepting, checking and paying grant applications), stakeholders (applicants, caseworkers, the finance office, the privacy office), assets (application data, the decision engine, payment instructions) and the authorisation boundary: the web front end, application services, database, document store and the agency-managed cloud account. The cloud provider's underlying infrastructure is outside the boundary but supplies inherited controls through its own authorisation. The team maps the life cycle of each information type, from the moment an applicant uploads a document to deletion after the retention period, and runs a system risk assessment that highlights account takeover, fraudulent applications and leakage of uploaded documents. The system is registered with the agency's programme office.

Categorize

The team identifies three information types: applicant personal and financial data, grant decision records and payment instructions. Losing confidentiality of applicant data would cause serious harm to individuals: moderate. Unauthorised changes to decisions or payment instructions could send money to fraudsters: moderate integrity. A day of downtime would delay applications but not cause serious harm: low availability. The overall category is moderate, the highest of the ratings. The AO's designated representative reviews the reasoning and the AO approves the categorisation.

Select

The team starts from the SP 800-53B moderate baseline and, because the system processes PII, the privacy baseline as well. Tailoring decisions include: scoping out controls for wireless networking, which the system does not use; adding stronger fraud-detection logging because the risk assessment flagged fraudulent applications; and setting organisation-defined values, such as locking accounts after a stated number of failed sign-ins. Physical protection controls are marked as inherited from the cloud provider; audit logging is hybrid (the provider supplies the logging platform, the team configures what to log); identity proofing for applicants is system-specific. The security and privacy plans are written in the agency's GRC tool, a monitoring strategy sets monthly vulnerability scanning and automated configuration checks, and the AO's designated representative approves the plans before build work starts.

Implement

Engineers build the portal with infrastructure as code, so encryption settings, network rules and logging configuration are defined in version-controlled templates. Two planned controls change during build: the team adopts the agency's enterprise sign-in service for caseworkers instead of a separate login, and replaces a planned manual review of uploaded files with an automated malware scan. Both changes are recorded in the plans, so the documentation describes the system as built.

Assess

The AO selects the agency's independent assessment team, which has no role in building the portal. Its plan, based on SP 800-53A, mixes document examination, interviews with the operations staff and technical tests including a penetration test. The privacy office assesses the privacy controls. The reports record twelve findings. Nine are fixed within two weeks and re-tested. Three remain: a medium-risk weakness in session timeout handling that needs a code change in the next release, an incomplete contingency test and a missing data-sharing agreement with the finance office. All three go into the POA&M with owners and dates.

Authorize

The system owner submits the package. The executive summary explains that the residual risks are limited and have dated fixes. The AO reviews the package with the senior agency information security officer and the privacy official, accepts the session-timeout risk for ninety days with an added compensating measure (shorter idle timeout configured at the gateway), requires the contingency test before the high-demand winter season, and issues an ATO. Because Northfield's monitoring is mature, the decision places the portal under ongoing authorisation with a quarterly AO review rather than a fixed expiry date. The decision is reported to the chief information officer's office and recorded in the system inventory.

Monitor

Automated scans and configuration checks feed a dashboard the AO's representative reviews monthly. Three months after go-live, the business wants to add a third-party service that checks income data against another agency's records. The team treats it as a significant change: the system risk assessment is updated, a new interconnection agreement is drafted, the plans are revised and the new connection is assessed before going live. The AO reviews the impact and confirms risk acceptance without a full reauthorisation. Two years later, when the grant programme ends, the disposal strategy guides secure deletion of applicant data according to the retention schedule and closure of the cloud account.

What the example teaches

Three lessons stand out. First, the organisation-level Prepare work meant the project could inherit training, incident response and identity controls rather than build them. Second, the categorisation drove everything that followed, which is why it deserves careful reasoning and approval. Third, the authorisation was a business decision by an accountable official, based on evidence, with conditions and a monitoring arrangement that kept it alive after go-live.

Lesson 7 – Relationship to other standards and frameworks

SP 800-37 is the process in the middle of a family of documents. It tells you what to do and who decides; the others supply the inputs, the catalogue, the test procedures or a different perspective.

Document	What it provides	How it relates to SP 800-37
FIPS 199 and FIPS 200	Impact levels for categorisation; minimum security requirements	Used in the Categorize step and as the basis for selecting baselines
SP 800-53 Rev. 5 and SP 800-53B	The catalogue of security and privacy controls; the low, moderate, high and privacy baselines	The source of controls chosen and tailored in the Select step
SP 800-53A	Assessment procedures for each control	Used to plan and conduct the Assess step and continuous monitoring
SP 800-39 and SP 800-30	Organisation-wide risk management; how to conduct risk assessments	Provide the three-level model and the risk assessment method behind Prepare and Authorize
SP 800-137	Information security continuous monitoring	Describes how to run the Monitor step and support ongoing authorisation
SP 800-160 Vol. 1 and SP 800-161	Systems security engineering; cybersecurity supply chain risk management	Revision 2 aligns its tasks with these engineering and supply chain practices
NIST Cybersecurity Framework 2.0	Outcome-based functions and profiles for managing cybersecurity risk	Says what outcomes to achieve; the RMF offers a detailed process for achieving them, and CSF profiles can be used in Prepare
ISO/IEC 27001	Requirements for an information security management system, certifiable by accredited bodies	Manages risk at organisation level with a certificate; the RMF authorises individual systems with no certificate. The two can coexist
FedRAMP	A US government programme for authorising cloud services	Applies the RMF to cloud offerings so agencies can issue an authorisation to use

A practical rule of thumb: if your question is "which safeguard?", look in SP 800-53; "how do I test it?", SP 800-53A; "how bad would a breach be?", FIPS 199; "who decides and when?", SP 800-37. Organisations outside government that already use ISO/IEC 27001 or the Cybersecurity Framework often borrow the RMF's system-level discipline, especially the boundary, the plan, the independent assessment and the explicit risk acceptance, without adopting the whole federal apparatus.

Common pitfalls and best practices

Pitfalls

• Treating the ATO as the goal. Teams rush to obtain a decision, then let monitoring lapse. The authorisation quietly becomes fiction as the system changes.
• Skipping or rushing Prepare. Without organisation-level roles, strategy and common controls, every system owner reinvents them and decisions become inconsistent.
• A vague or shifting boundary. Components that sit outside every boundary end up protected by nobody; an oversized boundary makes assessment impossible to finish.
• Documentation that describes the plan, not the system. Plans not updated after implementation lead to assessment findings and to AOs deciding on false information.
• Assuming inherited controls are fully covered. Hybrid controls leave a part for the system team, and inherited controls carry their own residual risk that the AO must understand.
• A POA&M that only grows. Weaknesses recorded but never worked, or closed without evidence, undermine the AO's trust and attract audit findings.
• Bolting security on at the end. Starting the RMF a few weeks before go-live makes changes expensive and invites pressure to accept avoidable risk.

Best practices

• Start the RMF at project initiation. Categorise and select early so that requirements shape the design, and align tasks with your development life cycle, including Agile sprints.
• Invest in common controls. Publish well-documented, authorised common controls so that systems can inherit them and assessments focus on what is unique.
• Automate evidence. Use infrastructure as code, configuration scanning and GRC tooling so that the same data serves implementation records, assessments and continuous monitoring.
• Define significant changes in advance. Agree with the AO which events trigger a review, so that teams neither ignore changes nor escalate trivial ones.
• Write the executive summary for the decision-maker. AOs are senior and busy; explain the residual risk, its business impact and the proposed response in plain language.
• Bring privacy in from the start. Involve the privacy office in Prepare and Categorize whenever personal data are processed, not only in the assessment.
• Move towards ongoing authorisation. Mature continuous monitoring lets the AO accept risk on current evidence instead of a three-yearly snapshot.

Summary and key takeaways

• NIST SP 800-37 Revision 2 (December 2018) is the current, final description of the Risk Management Framework; no newer revision has been released.
• The RMF is a process, not a control catalogue: it uses SP 800-53 controls, FIPS 199 categorisation and SP 800-53A procedures.
• The seven steps are Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor; Prepare was added in Revision 2.
• Prepare works at both organisation level and system level, so that strategy, common controls and priorities are reused by every system.
• The authorising official alone accepts risk; the decision cannot be delegated and, for federal systems, cannot be made by a contractor.
• Decisions are ATO, common control authorisation, authorisation to use or denial, based on plans, assessment reports, the POA&M and an executive summary.
• There is no RMF certificate; mature continuous monitoring allows ongoing authorisation instead of periodic reauthorisation.
• The framework applies to any type of system and any development method, and is used voluntarily well beyond the US government.

Reflection questions

1. Think of a system you work on. Where would you draw its authorisation boundary, and which components would be inherited from a platform or another team?
2. Which three information types does that system handle, and how would you rate the impact on confidentiality, integrity and availability for each?
3. Who in your organisation would be the natural authorising official for that system, and what would that person need in an executive summary to make a confident decision?
4. What evidence about your controls could be collected automatically today, and what still depends on manual review?
5. Which changes to your system should count as significant enough to involve the decision-maker again, and which should not?

Further reading and official sources

• SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations – NIST CSRC
• About the Risk Management Framework (steps, Quick Start Guides, FAQs) – NIST CSRC
• SP 1314, NIST RMF Small Enterprise Quick Start Guide – NIST CSRC
• SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations – NIST CSRC
• FIPS 199, Standards for Security Categorization of Federal Information and Information Systems – NIST CSRC
• SP 800-39, Managing Information Security Risk – NIST CSRC
• SP 800-137, Information Security Continuous Monitoring – NIST CSRC

Original tutorial by xOps School (DevOpsSchool Private Limited), written from public sources about NIST SP 800-37. Not affiliated with or endorsed by the standard's owner; standard names are trademarks of their owners. Buy the official standard from its publisher for the authoritative text.