NIST SP 800-37: The RMF Lifecycle Course — RMF Coach

Lesson 1 — Why the RMF, and by What Authority (~8 min)

The RMF isn't paperwork — it's how an organization manages risk to a defensible decision.

Explain why the RMF exists, who it's for, and the authority (FISMA) behind it.

A new teammate looks at everything ahead — categorize, select, implement, assess, authorize, monitor — and asks the honest question: "Why are we doing all this paperwork?"

It's the right question with the wrong word. None of this is paperwork for its own sake. It's a structured way to answer one thing: is the risk of operating this system acceptable, and who says so?

Federal organizations don't get to opt out. The Risk Management Framework (RMF) is the disciplined, repeatable process for managing information security and privacy risk across an organization. This course — built on NIST SP 800-37 Rev 2 — takes you from why the RMF exists through each of its seven steps. It's written for everyone who touches the process, at every experience level.

The goal of the RMF is to manage information security and privacy risk to organizational operations, assets, individuals, other organizations, and the Nation — and to do it consistently with the organization's mission and risk strategy.

Its authority is the law. The Federal Information Security Modernization Act (FISMA) requires every federal organization to run a risk-based information security program, and NIST develops SP 800-37 to carry out its statutory responsibilities under FISMA. So the RMF isn't a NIST suggestion you may adopt — it's how federal organizations satisfy a legal obligation.

By the end, you'll be able to place risk at the right organizational level, name the seven steps and what each is for, and understand the roles and authorization decisions that hold it all together. That's the map for the rest of the course.

Lesson 2 — The Laws Behind the RMF (~9 min)

Behind the process is a stack of laws — know what each requires of you.

Identify the legislation and policy that mandate federal information security and what FISMA requires.

Federal security practices don't come from IT departments — they come from Congress, and they're overseen and coordinated by the Office of Management and Budget (OMB).

These mandates do three things: they govern how federal information security practices are created and implemented; they place responsibility and accountability for information security at all levels within an agency, from the C-suite to the system owner; and they make security subject to reporting and oversight.

That's why the RMF feels formal: it produces the evidence and decisions that satisfy real legal accountability. The paperwork a new practitioner sees is, in fact, the audit trail that lets a senior official stand behind a risk decision when Congress or an inspector general asks.

A few names anchor the whole framework.

The E-Government Act of 2002, Title III — the Federal Information Security Management Act (FISMA 2002) — required each agency to develop, document, and implement an agency-wide program to secure its information and systems, including those run by contractors. The Federal Information Security Modernization Act of 2014 (FISMA 2014) updated it.

The Paperwork Reduction Act (1995) and the Information Technology Management Reform Act (1996) explicitly emphasized a risk-based policy for cost-effective security. And *OMB Circular A-130, Managing Federal Information as a Strategic Resource, establishes the general policy for planning, budgeting, governing, acquiring, and managing federal information and IT — including the privacy requirements that the RMF now integrates.

Together they say the same thing the RMF operationalizes: protect federal information commensurate with risk*, and be accountable for it.

FISMA gets specific. It requires federal organizations to:

provide information security protections commensurate with the assessed risk;

ensure senior leaders provide security for the assets under their control;

ensure the organization has trained personnel to help comply;

provide annual reports on the adequacy and effectiveness of their security policies, procedures, and practices;

develop, document, and implement an information security program; and

develop and maintain an inventory of systems.

Notice how directly these map to RMF outputs. "Commensurate with risk" is categorization and tailoring. "Senior leaders provide security" is the authorizing official accepting risk. "Annual reports" and the "inventory" are continuous monitoring. The RMF isn't a parallel exercise — it's the machinery that produces exactly what FISMA demands.

Lesson 3 — SP 800-37 and the Rev 2 Updates (~10 min)

800-37 Rev 2 widened the RMF: privacy, supply chain, engineering, and a new Prepare step.

Describe SP 800-37's purpose and the major changes introduced in Revision 2.

SP 800-37 is the publication that defines the Risk Management Framework. Its purpose is to promote an organization-wide risk management process covering both information security and privacy — managed consistently with mission and the overall risk strategy, with a consistent risk posture across the organization, requirements integrated into the enterprise architecture, clarity on who accepts risk, and the information senior leaders need to make decisions.

It has history: first published in 2004, Revision 1 in 2010 (updated 2014), and the current Revision 2 on December 20, 2018. NIST develops it to carry out its statutory responsibilities under FISMA.

Keep the relationship straight: SP 800-53 is the catalog of controls, SP 800-53B is baselines, SP 800-53A is assessment — and SP 800-37 is the process that ties them together into a risk decision. This course is that process.

Revision 2 substantially widened the RMF. The headline changes:

a brand-new Prepare step, at both the organization level and the system level, added in front of Categorize;

alignment and integration of supply chain risk management, privacy, the Cybersecurity Framework (CSF), and systems security engineering into the RMF;

guidance on how the RMF is implemented across the system development life cycle (SDLC);

potential inputs and expected outputs specified for every RMF task; and

closer linkage between governance-level (C-suite) and operational-level work, so risk decisions connect top to bottom.

The through-line of Rev 2 is integration: instead of security risk managed in a silo, the RMF became the place where security, privacy, supply chain, and engineering risk are managed together, with explicit hand-offs. The next screens walk those integrations one at a time.

Rev 2 made privacy a first-class concern, in accordance with OMB A-130. Rather than a separate process, privacy risk management is woven through the RMF.

Concretely: there's a dedicated treatment in Section 2.3, Information Security and Privacy in the RMF; privacy is called out in task text where it applies (for example, Task P-3 assesses security and privacy risk); privacy-specific inputs, outputs, roles, and references appear in tasks as appropriate; and task discussions include privacy-specific detail.

The practical effect: a privacy office and a Senior Agency Official for Privacy (SAOP) aren't running a side process — they're participants in the same RMF tasks, at the same time, with defined responsibilities. When a system processes PII, privacy considerations ride along through Categorize, Select, Assess, Authorize, and Monitor, not after.

Rev 2 didn't just add privacy — it connected the RMF to three more disciplines.

Cybersecurity Framework (CSF): task inputs and outputs reference the CSF where applicable (e.g., a CSF profile as a potential output of Task P-4), and outcome tables and references point to relevant CSF categories — so an organization using the CSF for governance and the RMF for authorization isn't doing double work.

Systems Security Engineering (SSE): the RMF aligns its steps and tasks with the engineering processes in NIST SP 800-160, Volume 1, and new Prepare system-level tasks were added to line up with system security engineering — building security in during development rather than bolting it on.

Supply Chain Risk Management (SCRM): Rev 2 added Section 2.8 on SCRM within the RMF, with supply-chain considerations in task discussions, artifacts in task inputs and outputs, and responsibilities in Appendix D.

The pattern is consistent: the RMF became the integration hub where these risk disciplines meet a single authorization decision.

The RMF isn't a gate at the end of a project — it runs across the system development life cycle (SDLC).

Rev 2 makes this explicit: each task in SP 800-37 describes its primary responsibility (the role that owns it), its supporting roles, and the SDLC phase where the task is executed. So categorization and control selection happen during design; implementation and assessment during build and test; authorization before operation; and monitoring throughout operation and into disposal.

Why it matters: security and privacy built into the life cycle are cheaper and stronger than protections retrofitted afterward. Knowing which SDLC phase a task belongs to tells you when to do the work — and who's on the hook for it — instead of discovering at the end that a system can't be authorized.

That foundation set, Module 2 turns to the fundamentals the whole framework rests on: organization-wide risk, the seven steps, system elements, boundaries, authorization types, and the roles that carry it out.

Lesson 1 — Organization-Wide Risk Management (~8 min)

Risk isn't only a system problem — it's managed at three levels of the organization.

Place risk at the three organizational levels and describe the frame/assess/respond/monitor cycle.

Security and privacy risk management is the process of managing the risk to an organization that results from operating or using systems. To do that well, the RMF uses a three-level approach so risk is addressed everywhere it lives, not just at the system:

Level 1 — Organization: enterprise-wide risk strategy, governance, and tolerance.

Level 2 — Mission / Business Processes: risk to the missions the systems support.

Level 3 — System: the risk of an individual system's operation.

The levels connect top-down and bottom-up. Level 1 sets the risk strategy and tolerance that constrain what Level 3 can accept; Level 3's real-world risk informs Level 1. A system owner who only looks at their own system, ignoring the organization's strategy, will make decisions the organization can't actually live with.

At every level, managing risk is a comprehensive process with four parts (from NIST SP 800-39):

Frame risk: establish the context for risk-based decisions and produce a risk management strategy — assumptions, constraints, tolerance, and priorities.

Assess risk: identify threat sources and vulnerabilities, the potential mission/business impact, and the likelihood of occurrence.

Respond to risk: decide on a consistent, organization-wide response — accept, avoid, mitigate, share, or transfer.

Monitor risk: track how risk and the effectiveness of responses change over time.

The RMF is how this cycle is carried out for systems specifically. Categorize and Select are assessment and framing; Implement and Assess execute and verify the response; Authorize is the formal risk acceptance; Monitor keeps watch. Seeing the cycle underneath keeps the steps from feeling arbitrary.

A key to success is a broad-based, organization-wide perspective and support. Risk management can't be one team's project off in a corner — it needs leadership backing and participation across missions, IT, security, and privacy.

And the objective is easy to lose sight of in the paperwork: it's to enable the organization to conduct its day-to-day operations and accomplish its missions. Managing the risk from operating systems is critical to the mission — security isn't the goal, it's what makes the mission survivable.

That reframing matters for a practitioner. When a control feels like an obstacle, the question isn't "how do we avoid this control" but "how do we protect the mission at a cost the organization accepts." The whole framework exists to answer that — defensibly, at the right level, with the right people.

Lesson 2 — The Seven Steps & Task Structure (~9 min)

Seven steps, each with a purpose, outcomes, and tasks — and every task has the same anatomy.

Name the seven steps and describe the structure of a step and a task.

The RMF has seven steps: a preparatory Prepare step to ensure organizations are ready, then six main steps — Categorize, Select, Implement, Assess, Authorize, Monitor.

Two things to hold onto. First, organizations have flexibility in how they implement each step and task, as long as they meet the applicable requirements and effectively manage security and privacy risk — the RMF is a framework, not a rigid script. Second, all seven steps are essential; skipping one breaks the chain that leads to a defensible authorization.

The order is a logic: get ready (Prepare), decide how much protection (Categorize), choose controls (Select), build them (Implement), check them (Assess), accept the risk (Authorize), and keep watching (Monitor). Module 3 takes each step one at a time; this module first lays the fundamentals they all rely on.

Every RMF step is built the same way: a purpose statement, a set of outcomes, and the tasks carried out to achieve them.

Take the Implement step as the example the course uses: its purpose is to implement the controls in the security and privacy plans for the system and the organization, and to document the specific details of the implementation in a baseline configuration. Its outcomes state what "done" looks like, and its tasks are the concrete work.

Rev 2 also ties each step's outcomes to applicable Cybersecurity Framework components, so organizations using both can see how they line up. The point for you: when you open any step, look for these three things — why (purpose), what done means (outcomes), and the work (tasks). It makes a dense document navigable.

Zoom in one more level. Each task has a defined structure — and Rev 2 added two of these fields:

Task section: describes the specific task within its step.

Potential inputs (NEW): the information that may be needed to complete the task.

Expected outputs (NEW): the end result of completing the task.

Primary responsibility: the individual or group accountable for ensuring the task is completed.

Supporting roles: who else contributes.

The inputs/outputs additions are quietly important: they make the RMF a connected pipeline where one task's outputs feed the next task's inputs, with clear hand-offs. And naming a primary responsibility for every task is what makes accountability real — there's always someone who owns getting it done, not a diffuse "the team." When you execute a task, find these fields first: what do I need, what must I produce, and am I the owner or a supporter?

Lesson 3 — Security & Privacy in the RMF (~7 min)

Securing PII protects privacy — but privacy needs more than security.

Explain the security/privacy relationship and the role of the PRAM.

Security and privacy overlap, but they aren't the same. Securing PII plays an important role in protecting privacy — yet individual privacy cannot be achieved solely by securing PII.

The reason is authorized processing. A system's normal, authorized operations on PII — collection through disposal, done to achieve the mission — can themselves create privacy risk, even when nothing is breached. Over-collection, unexpected secondary use, or opaque processing are privacy problems that perfect security doesn't solve.

So the RMF treats this as a shared responsibility: the security team manages risks from unauthorized activity, and the privacy team manages risks to individuals from authorized processing — together, through the same RMF tasks. When a system handles PII, you need both lenses, which is exactly why Rev 2 wove privacy into the framework rather than leaving it to security alone.

To assess privacy risk specifically, NIST provides the Privacy Risk Assessment Methodology (PRAM). It applies the privacy risk model from NISTIR 8062 and helps an organization analyze, assess, and prioritize privacy risks so it can decide how to respond and which solutions to select.

Just as importantly, the PRAM drives collaboration — it brings privacy, cybersecurity, business, and IT people to the same table, because privacy risk decisions cut across all of them. Once the organization decides which risks to mitigate, the PRAM informs the selection of appropriate controls and other responses.

The takeaway: privacy risk gets a deliberate method, not an afterthought. When a system processes PII, the PRAM is how the privacy side does the "assess risk" part of the cycle, feeding the same Select and Authorize decisions the security side feeds.

Lesson 4 — System & System Elements (~6 min)

Know precisely what 'the system' means before you try to protect it.

Define a system and its elements and read the relational view of a system-of-interest.

The RMF borrows its definition of "system" from systems engineering. Per ISO/IEC 15288, a system is a set of interacting elements organized to achieve one or more stated purposes. System elements are what's implemented to fulfill the system's requirements.

Crucially, elements aren't only technology. They include technology/machine elements (hardware, software, firmware), human elements (people and roles), and physical/environmental elements (facilities, power, environment). A definition that stopped at "the servers" would miss the people and places that are equally part of the system — and equally in scope for protection.

This matters for boundaries and control selection. When you decide what to protect, you're protecting the system as interacting elements, which is why controls span technical, personnel, and physical families. Getting the definition right keeps you from leaving whole categories of risk out of scope.

The relational view places your system-of-interest in context. The system sits inside an authorization boundary, surrounded by:

other systems it interacts with,

enabling systems that support it (e.g., development or operations infrastructure that isn't part of the system itself), and

the environment of operation it runs in.

This conceptual view applies to the system-of-interest, not to individual system elements — you draw the picture around the whole system, not around each component.

Why bother with the diagram? Because it's the setup for the single most consequential scoping decision in the RMF: where the authorization boundary goes. Seeing your system among other and enabling systems makes the boundary question concrete — what's inside (and so your responsibility) versus outside (someone else's, possibly inherited). That's the next lesson.

Lesson 5 — Authorization Boundaries (~8 min)

The boundary decides what's protected, who's accountable, and how big the job is.

Define an authorization boundary, its considerations, and how complex systems are divided.

Terminology first: to keep things consistent, "system boundary" is no longer used interchangeably with "authorization boundary." Use authorization boundary.

The authorization boundary does two big things. It establishes the scope of protection — what is to be protected as part of a given system — and it defines the scope of the authorizing official's responsibility and accountability for protecting information resources and individuals' privacy. It's formally established during Task P-11 (Authorization Boundary) in the Prepare step.

This is one of the highest-leverage decisions in the RMF. Draw the boundary too wide and you take on protecting (and assessing) things you don't control; too narrow and you exclude things you do — leaving real risk unmanaged. Everything downstream — categorization, control selection, assessment, the AO's risk acceptance — is scoped by this line. Get it right early.

Large systems don't have to be one monolithic boundary. Dividing a system into subsystems facilitates a targeted application of controls — achieving adequate security and privacy protection more cost-effectively, because you apply the right controls to each part rather than the heaviest controls to everything.

This also handles external providers. When part of a system is delivered by an external service, the boundary and subsystem structure clarify what's inside your authorization (your responsibility) versus what you inherit or rely on from the provider. Different subsystems can carry different protections appropriate to their risk.

The judgment is the same as the boundary itself: divide where it helps you apply controls precisely and assign responsibility clearly. Done well, subsystem boundaries turn an unmanageable "protect everything equally" problem into a set of right-sized, individually defensible pieces — which is exactly what makes a complex system authorizable at all.

Lesson 6 — Authorization Types & Decisions (~11 min)

Authorization comes in types (when) and decisions (what the AO grants).

Distinguish the authorization types and the authorization decisions an AO can make.

Authorization comes in three types, distinguished by when and how:

Initial authorization is the start-up risk determination and acceptance, based on a complete, zero-based review — assessing all implemented system-level controls and reviewing the status of inherited common controls. (A zero-based review of the system doesn't require re-reviewing the common controls it inherits.)

Ongoing authorization is the follow-on decisions made at agreed, documented frequencies (time-driven) and when thresholds are exceeded (event-driven) — continuous risk acceptance rather than a cliff-edge re-do. It's the modern target state, fed by continuous monitoring.

Reauthorization is a static, single point-in-time risk determination after the initial one — time- or event-driven, and a separate activity from ongoing authorization. Both ongoing and reauthorization can be a full zero-based assessment or a targeted assessment based on what triggered them.

The key contrast: ongoing authorization is continuous; reauthorization is a discrete redo.

An authorization decision is what the Authorizing Official (AO) actually issues. The two that grant operation:

Authorization to Operate (ATO): issued by the AO after determining the risk to operations, assets, individuals, other organizations, and the Nation is acceptable. It specifies an authorization termination date (or, under ongoing authorization, a time-driven frequency), and the AO may include operating restrictions as conditions.

Common Control Authorization: the same idea, but issued for common controls rather than a system. It also carries a termination date or ongoing frequency. Note the nuance: common controls implemented as part of a system don't need a separate common control authorization — this decision is for controls offered for inheritance across systems.

Both are acts of accountability: a named senior official looks at the evidence and personally accepts the risk. That's the whole point of the Authorize step — risk acceptance has an owner.

Two more decisions complete the core set.

Authorization to Use (ATU): used when a customer organization, after reviewing an existing authorization package, accepts the ATO issued by an AO at another federal entity (the provider organization). It's issued by an official with the same level of risk-management authority as an AO, and it indicates acceptance of the risk of using that already-authorized system. This is "do once, use many" inside government — reuse an authorization instead of redoing it.

Denial of Authorization: AOs should not feel pressured into accepting unacceptable risk. When existing risk is unacceptable — significant control deficiencies, risk not managed within the organization's strategy and tolerance — the AO denies the ATO, common control authorization, or ATU. Denial isn't a failure of the process; it's the process working: the accountability mechanism refusing to put the organization in harm's way.

Together, ATO/CCA/ATU/denial are the AO's full vocabulary: grant, grant-for-inheritance, reuse, or refuse.

Beyond the core decisions, Rev 2 names four specialized forms for particular situations:

Type Authorization: a single authorization for a common version of a system — used when a system is many identical instances (same architecture, software, information types). Authorize once, deploy the copies; often paired with a facility authorization.

Facility Authorization: authorizes the common controls provided in a specific environment of operation (a data center, say), at a specified impact level, that hosted systems then inherit.

Traditional Authorization: a single organizational official in a senior role makes the risk-acceptance decision — the default, one-AO model.

Joint Authorization: multiple authorizing officials share the decision, used when a system crosses organizational lines and more than one entity must accept the risk together.

You don't need to apply these daily, but recognizing them keeps you from being confused when a package says "type-authorized" or "joint authorization" — they're just the right tool for replicated, facility-based, single-, or multi-owner situations.

Lesson 7 — Requirements, Posture & Supply Chain (~8 min)

Three fundamentals that thread the whole framework: what's required, where you stand, and who you depend on.

Distinguish requirements from controls, define security/privacy posture, and explain SCRM in the RMF.

"Requirements" and "controls" can mean different things in different contexts, so the RMF is careful.

A requirement, in federal security and privacy policy, includes legal and policy obligations and a broader expression of stakeholder protection needs derived from other sources. Requirements help determine the required characteristics of the system — its security and privacy properties.

A control, by contrast, is the safeguard you implement to satisfy a requirement (from the SP 800-53 catalog). Requirement is the what/why; control is the how.

Why the care? Because a control selected without a clear requirement is effort with no justification, and a requirement with no control is an unmet obligation. The RMF keeps the chain visible: obligations and needs → requirements → selected, tailored controls → assessed evidence. When a package talks about "requirements," it means that upstream layer — not the controls themselves.

Security and privacy posture is the status of systems, information resources, and IT capabilities in an organization — based on its information-assurance resources (people, equipment, funds, hardware, software, policies, procedures).

The key word is ongoing. Posture is determined continuously, by assessing and monitoring the system-specific, hybrid, and common controls. It isn't a snapshot from authorization day — it's the living picture of how protected the system actually is right now.

And it has a consumer: authorizing officials use posture to determine whether the risk to operations, assets, individuals, and others remains acceptable. That's the bridge from the Monitor step back to the Authorize decision. When posture degrades — a control fails, a new vulnerability lands — the AO has the information to reconsider risk acceptance, possibly triggering a reauthorization. Posture is, in effect, the signal the whole monitoring apparatus exists to produce.

Modern systems are assembled from external component products, systems, and services — and that introduces supply chain risk. Rev 2 makes clear: the organization and the authorizing official are ultimately responsible for responding to risks from using external providers. You can outsource the component; you can't outsource the accountability.

Supply Chain Risk Management (SCRM) is a complex, multifaceted undertaking that requires a coordinated effort across the organization. Organizations develop a SCRM Strategy, Policies, and Plans to direct it, and SCRM activities run throughout — identifying, assessing, and responding to risks introduced by suppliers and components.

In the RMF, SCRM isn't a separate track: supply-chain considerations appear in task discussions, supply-chain artifacts show up in task inputs and outputs, and responsibilities are assigned (Appendix D). The practical mindset: every external dependency is part of your risk picture, owned by you, and managed through the same framework — not waved away because "the vendor handles it."

Lesson 8 — Risk Management Roles (~10 min)

The RMF is run by people in defined roles — know who owns what.

Identify the key RMF roles across governance, system ownership, and specialists.

The RMF defines roles for everyone in the risk process (titles vary by organization, but the responsibilities are consistent). Start at the top, with governance:

Authorizing Official (AO): the senior official who accepts risk and authorizes a system to operate — the accountability anchor of the whole framework.

AO Designated Representative (ADR): acts for the AO on day-to-day risk activities, but cannot make the authorization decision itself.

Senior Accountable Official for Risk Management (SAORM): leads the risk executive function; is the head of the agency or their designee.

Risk Executive (Function): provides the organization-wide view of risk, ensuring system-level risk is seen from an enterprise perspective.

C-Suite Officials: oversee security/privacy programs and ensure accountability in their areas.

Senior Agency Information Security Officer (SAISO): carries out the CIO's FISMA security responsibilities; the CIO's liaison.

Senior Agency Official for Privacy (SAOP): ensures privacy compliance and manages privacy risk, coordinating with the SAISO.

The pattern: this tier sets the strategy and tolerance, and the AO personally accepts the risk a system carries.

Below governance are the roles that actually own and operate a system:

System Owner: responsible for the procurement, development, integration, modification, operation, maintenance, and disposal of a system — and for addressing its security and privacy throughout. The system's accountable manager (who assembles the authorization package).

Information Owner / Steward: has management or operational authority for specified information, and sets the policies and procedures for its generation, collection, processing, dissemination, and disposal.

Common Control Provider: responsible for the implementation, assessment, and monitoring of common controls — the shared protections that organizational systems inherit.

System Security or Privacy Officer (ISSO/SPO): ensures the system's operational security and privacy posture is maintained, working closely with the system owner day to day.

This tier is where the RMF stops being abstract: someone procures and runs the system (owner), someone owns its data (information owner), someone provides the shared controls (common control provider), and someone keeps the posture healthy in operation (ISSO).

Finally, the specialists who design, engineer, and independently check:

Control Assessor: conducts a comprehensive assessment of implemented controls to determine their effectiveness, and writes up the results (the SAR). Independence here is what gives the AO confidence.

Enterprise Architect: implements an enterprise architecture strategy that enables effective security and privacy solutions, coordinating with the security/privacy architects.

Security or Privacy Architect: ensures stakeholder protection needs and system requirements are met; the primary liaison translating needs into architecture.

System Security or Privacy Engineer (SSE): part of the development team — designs and builds (or upgrades) systems with security and privacy engineered in, and supports continuous monitoring.

Notice the spread: architecture and engineering build protection in (cheaper, stronger), while the assessor verifies it independently. Across all three tiers — governance, ownership, specialists — the RMF's design is that no single person both builds and blesses their own work. That separation is what makes an authorization trustworthy.

Pull the fundamentals together. Risk is managed at three levels (organization, mission, system) through a cycle of frame, assess, respond, monitor. The RMF runs that cycle for systems in seven steps, each built from a purpose, outcomes, and tasks, and each task with inputs, outputs, and an owner.

You protect a system — interacting technology, human, and physical elements — scoped by an authorization boundary that sets what's protected and whose accountability it is. The authorizing official then makes a decision: ATO, common control authorization, ATU (reuse), or denial, in an initial, ongoing, or reauthorization posture. Throughout, security and privacy are managed together, requirements drive controls, posture is watched continuously, and supply-chain risk stays the organization's responsibility.

And it's all carried out by defined roles — governance accepting risk, owners running systems, specialists building and independently assessing — so no one blesses their own work. With that foundation set, Module 3 walks each of the seven steps in action.

Lesson 1 — Overview of the RMF (~5 min)

Before the steps, the payoff: why this framework is worth running.

State the benefits of the RMF and that every step is required.

Before walking the steps, it's worth naming what the RMF actually delivers. It gives an organization:

a structured yet flexible process for managing the risk of operating systems;

guidance on the appropriate risk mitigation needed to protect the systems and infrastructure that support the mission; and

a repeatable methodology that balances mission/business goals against security and privacy risk.

That balance is the heart of it. The RMF isn't "maximum security at any cost" — it's enough protection, chosen deliberately, so the mission can run at a risk the organization accepts. And because it's repeatable, every system goes through the same defensible path, and every authorization rests on the same kind of evidence.

Organizations are expected to execute all steps and tasks, with flexibility in how, as long as requirements are met and risk is managed. The next lessons take each step — Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor — in turn.

Lesson 2 — Step 1: Prepare (~8 min)

Prepare gets the organization and the system ready — the Rev 2 step that sets everything up.

Describe the purpose of Prepare and its organization- and system-level tasks.

Prepare is the step Rev 2 added at the front. Its purpose: carry out essential activities at all three risk levels to ready the organization to manage security and privacy risk with the RMF.

At the organization / mission level, the tasks (P-1 onward) establish the foundation:

P-1 Risk Management Roles: identify and assign people to the security/privacy risk roles (the ones from Module 2).

P-2 Risk Management Strategy: establish the org's risk strategy, including its risk tolerance.

P-3 Risk Assessment (Organization): assess organization-wide risk and keep it current.

Plus tasks for the org-wide control baselines, common controls, and an impact-level prioritization.

The point of all this front-loading: you can't sensibly categorize or select controls for one system without the organization first deciding who's responsible, how much risk it tolerates, and what shared controls exist. Prepare puts those stakes in the ground so every system that follows starts from a known footing.

At the system level, Prepare gets the specific system ready (tasks P-13 onward):

P-13 Information Life Cycle: identify and understand every stage of the life cycle (creation to disposal) for each information type the system handles.

P-14 Risk Assessment (System): conduct a system-level risk assessment and keep it current.

P-15 Requirements Definition: define the system's security and privacy requirements.

Plus enterprise/architecture placement, requirement allocation, system registration, and — crucially — P-11 Authorization Boundary (Module 2's boundary decision lives here).

These tasks support publications you've met: SP 800-30 (risk assessments), SP 800-39 (organization-wide risk), SP 800-53B (baselines/tailoring), and SP 800-60 (mapping information types). Together, org- and system-level Prepare answer who, how much risk, what information, what requirements, and what boundary — so by the time you reach Categorize, the system is fully scoped and the rest of the RMF can run cleanly.

Lesson 3 — Step 2: Categorize (~6 min)

Categorize sets the stakes: how bad would loss of C, I, or A be?

Describe the purpose and tasks of the Categorize step.

Categorize sets the stakes. Its purpose: determine the adverse impact to the organization from the loss of confidentiality, integrity, and availability (C/I/A) of the system and its information — so all later risk decisions are informed by how much is at risk.

Its tasks are tight:

C-1 System Description: document the system's characteristics.

C-2 Security Categorization: categorize the system (per FIPS 199) and document the results — the low/moderate/high impact level.

C-3 Security Categorization Review and Approval (NEW in Rev 2): review and approve the categorization decision, so it isn't one person's unchecked call.

It's supported by FIPS 199, SP 800-60 (mapping information types to impact), and SP 800-18r2 (system plans — the SSP plus system privacy and C-SCRM plans). The output — an impact level — is the hinge of the whole framework: it determines the baseline you'll select from in the next step, and through that, how much protection the system gets. Categorize too low and you under-protect; too high and you waste resources. It's worth getting right and getting approved.

Lesson 4 — Step 3: Select (~6 min)

Select turns an impact level into a tailored, documented control set.

Describe the purpose and tasks of the Select step.

Select turns the impact level into an actual control set. Its purpose: select, tailor, and document the controls needed to protect the system and organization commensurate with risk. This is where SP 800-53 (catalog), 800-53B (baselines/tailoring), and FIPS 200 plug into the RMF.

The tasks mirror the 800-53B course:

S-1 Control Selection: select controls for the system and its environment (start from the baseline).

S-2 Control Tailoring (NEW): tailor the selected controls (scope, compensate, set ODPs, supplement).

S-3 Control Allocation (REVISED): allocate controls to the system vs. the environment (system-specific, common, hybrid).

S-4 Document Planned Control Implementations (NEW): document the controls — the planned implementation — in the system security plan (SSP).

Notice the output is a plan, not yet a built system: the SSP says what controls you intend and how. That plan is exactly what the next step, Implement, turns into reality, and what Assess later checks against. Select is the bridge from "how much risk" to "here's our documented answer."

Lesson 5 — Step 4: Implement (~5 min)

Implement builds the controls and records how they were actually done.

Describe the purpose and tasks of the Implement step.

Implement does the building. Its purpose: implement the controls in the security and privacy plans, and document the specifics in a baseline configuration of the system.

Two tasks:

I-1 Control Implementation: implement the controls as specified in the plans.

I-2 Update Control Implementation Information (REVISED): document any changes between the planned implementation and the as-implemented state.

That second task is the quiet discipline that separates good programs from bad ones. Plans drift during build — a control gets configured slightly differently, a compensating measure is added, a parameter changes. If the SSP still describes the planned state while the system runs the as-built state, the assessor will test against the wrong thing and the authorization rests on fiction. Implement keeps the documentation honest — matching what's actually running.

It's supported by configuration-management and operational guides (SP 800-128, 800-34, 800-61, 800-86). The output: real, running controls and documentation that matches them — exactly what Assess needs next.

Lesson 6 — Step 5: Assess (~6 min)

Assess independently verifies the controls work — the evidence behind the decision.

Describe the purpose and tasks of the Assess step.

Assess is the verification step. Its purpose: determine whether the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to the system's security and privacy requirements. This is the SP 800-53A course's home in the RMF.

Tasks:

A-1 Assessor Selection (NEW): select the appropriate, suitably independent assessor or team.

A-2 Assessment Plan: develop, review, and approve the plan (the SAP) for assessing the controls.

A-3 Control Assessments: assess the controls per the plan's procedures.

A-4 Assessment Reports: document the results in the Security Assessment Report (SAR), with findings of satisfied or other-than-satisfied.

Plus remediation and a plan of action (POA&M) for what wasn't satisfied.

The critical property is independence: the assessor isn't the person who built the controls, so the AO gets an honest verdict rather than a self-graded one. The SAR that comes out is the core evidence the authorizing official will weigh — "do these controls actually work?" — in the next step.

Lesson 7 — Step 6: Authorize (~10 min)

Authorize is the moment a named official accepts the risk — or doesn't.

Describe the Authorize step's tasks and make an authorization decision from a package.

Authorize provides accountability: it requires a senior management official to determine whether the security and privacy risk of operating a system (or using common controls) is acceptable. This is the decision the entire framework builds toward.

The tasks:

R-1 Authorization Package: assemble the package — the SSP, the SAR, and the POA&M — and submit it to the AO.

R-2 Risk Analysis and Determination (REVISED): analyze and determine the actual risk of operating the system.

R-3 Risk Response (NEW): identify and implement the preferred response to the determined risk.

R-4 Authorization Decision: the AO issues the decision — ATO, common control authorization, ATU, or denial.

R-5 Authorization Reporting: report and document the decision.

The package is the whole story: what was planned (SSP), whether it works (SAR), and what's left undone with a fix plan (POA&M). The AO reads that story and makes a personal, accountable judgment. There are no more NIST publications listed for this step — by now, the inputs are everything the prior steps produced. Next, you'll step into the AO's chair.

Authorize the Harbor Benefits System (Moderate; processes claimant PII). System owner Marcus assembles the authorization package: the SSP (planned + as-built controls), the SAR from independent assessor Priya, and a POA&M for the open items.

Karen, the Authorizing Official, reads the story. The SAR shows most controls satisfied, but two are other-than-satisfied: multi-factor authentication isn't yet enforced for one admin path, and log retention falls short. The POA&M commits to fixing both within 60 days, and compensating measures (restricted network path, manual review) reduce the exposure meanwhile. Karen weighs the residual risk against the organization's risk tolerance and the mission need to deliver benefits on time.

She issues an ATO with a termination date and an operating restriction: the open admin path stays disabled until MFA is in place. That's the Authorize step in one breath — a named official, looking at real evidence, accepting a specific level of risk with specific conditions, and owning that decision. Your turn: a different situation lands on Karen's desk.

Lesson 8 — Step 7: Monitor (~6 min)

Monitor keeps the authorization honest — the RMF is never 'one and done.'

Describe the purpose and tasks of the Monitor step.

Monitor is the step that makes the RMF continuous. Its purpose: maintain ongoing situational awareness of the security and privacy posture of the system and organization, to support risk decisions.

Its tasks keep the picture current:

M-1 System and Environment Changes: watch for changes that affect posture.

M-2 Ongoing Assessments: reassess controls per the continuous monitoring strategy.

M-3 Ongoing Risk Response: respond to risk as monitoring reveals it.

M-4 Authorization Package Updates: keep the SSP/SAR/POA&M current.

M-5 Security and Privacy Reporting: report status to officials on an ongoing basis.

M-6 Ongoing Authorization: review the reported status so the AO can keep, adjust, or revoke the authorization — feeding ongoing authorization and reauthorization.

M-7 System Disposal: retire the system securely at end of life.

The whole point, stated plainly in the source: the RMF is not a compliance or "one-and-done" process. An ATO is a decision about risk at a point in time; Monitor is what keeps that decision honest as the system and its threats change — closing the loop back to Authorize, supported by SP 800-137 (ISCM).

Lesson 9 — Conclusion (~4 min)

Risk management is ongoing, coordinated, and in service of the mission.

Summarize the RMF and its key takeaways.

Put it all together. The RMF is how a federal organization manages security and privacy risk — under the authority of FISMA, defined by SP 800-37 Rev 2, integrating privacy, supply chain, engineering, and the CSF.

It runs seven steps: Prepare (get ready), Categorize (set the stakes from C/I/A impact), Select (choose and tailor controls), Implement (build them), Assess (independently verify them), Authorize (a named official accepts the risk), and Monitor (keep watch). Risk is managed at three levels, scoped by an authorization boundary, carried by defined roles where no one blesses their own work.

The key takeaways the course leaves you with: managing security and privacy risk supports the mission; it relies on coordination across programs and people; and it's driven by legislation and policy — not optional. Above all, the RMF is not "one and done": it's an ongoing activity that keeps systems trustworthy over their whole life.

That's the process RMF Coach lets you play — categorize, select, assess, authorize, and monitor a real system, at high tempo, until the moves are second nature.