SP 800-18r2: System Security Plans Course — RMF Coach

Lesson 1 — What a System Plan Is For (~8 min)

The documents — or data — that tell leadership how a system is actually protected.

Explain what a system plan is, who requires it, and the living-document standard it must meet to be useful.

Karen Diaz, the Authorizing Official, has thirty minutes before a decision meeting about MCMS, the system that tracks federal benefit case files. Her questions are concrete. What does this system do, and for whom? Where does its boundary run? What protects the PII inside it? Who is responsible when something breaks? What risks is she accepting if she signs?

The system plan is where those answers live. Not scattered across tickets, wikis, and tribal memory — consolidated, current, and organized so the people deciding about the system can actually find them.

Dana Okafor, the ISSO, maintains that plan. This course is about doing her job the way NIST SP 800-18r2 describes it — including the parts that are new in Revision 2.

In SP 800-18r2, system plans is a collective term. It covers the system security plan, the system privacy plan, and the cybersecurity supply chain risk management plan — the C-SCRM plan. Together they describe how a system's protections are designed and implemented across its whole life cycle.

That coverage is broad on purpose. The plans describe the data the system creates, collects, uses, stores, and disposes of. They name the individuals responsible for managing the system's risk. They describe the environment of operation, the components, and the data flows. And they account for the risks that come with sharing information beyond the system's own scope.

The mandate behind them is real. OMB Circular A-130 requires federal agencies to develop and maintain system plans, including implementation details for the controls allocated to each system, and FISMA gives that requirement statutory footing. Nonfederal organizations apply the guidance voluntarily — for SP 800-171 CUI system plans, for cloud service offerings, and anywhere a documented protection story is worth having.

SP 800-18r2 describes the system security plan as supporting situational awareness of the system's security posture across the life cycle. The publication's own phrase for this is a living document — a plan that tracks reality, not history.

Living is a discipline, not a mood. It means methodical reviews and periodic updates that keep the plan current on the system's mission, technologies, components, personnel, and control status. It also means every review and every change leaves a record. Rev 2 makes review records and change records named plan elements — part of the plan itself, not optional hygiene.

Hold that standard up to the plans you've seen. A plan that was accurate the day it was signed and untouched since has failed at its one job: giving decision-makers a current picture of how the system is protected.

Here's the sentence in Rev 2 that changes the most habits: organizations may consider more responsive approaches — automated data collection, online reporting dashboards — in lieu of traditional document-focused plans that can't keep pace with modern development.

Read that again. The plan is the information, not the binder. If the boundary description, control statuses, and open weaknesses are current in a repository, the plan is alive — whether or not anyone has exported a PDF this quarter.

That shift gets a full lesson in Module 3. For now, carry the standard forward: whatever form the plan takes, it exists so someone like Karen can decide from current information.

Lesson 2 — Three Plans, Three Lenses (~9 min)

Three plans, three risk lenses — one system, one coherent story.

Route a given risk to the right plan — security, privacy, or C-SCRM — and decide when to consolidate the three.

Three messages are waiting for Dana on Monday morning, all about MCMS. Tom Becker, the Senior Agency Official for Privacy, wants to know where the risks of a newly collected data field are documented. The platform team reports that the file-scanning vendor has swapped subcontractors. And Karen Diaz asks whether the access protections she approved are still implemented as described.

One system — but three different kinds of risk, read by three different officials. Each answer lives in a plan built for that lens: the system security plan, the system privacy plan, and the C-SCRM plan.

By the end of this lesson you'll route each message to the right plan without hesitating, and you'll know when it makes sense to keep the three as one consolidated document.

Start with the anchor. The system security plan identifies the system's security requirements and describes the controls planned and implemented to meet them. It consolidates the system's purpose, its authorization boundary, its FIPS 199 categorization, its operational status, and its environment of operation — and it names the people responsible for maintaining the protections.

Its organizing question is the classic security one: how do the controls achieve confidentiality, integrity, and availability for this system? For Dana, that question is the daily work. Every control allocated to MCMS gets an implementation description specific enough that an assessor can test against it.

The other two plans follow this pattern — same system, same discipline, different risk lens. That's the shape in the figure: three plans, three questions, one consistent story about one system.

The system privacy plan identifies the controls allocated and implemented to manage privacy risk — and its scope is wider than breach protection. It covers privacy risks from cybersecurity events and from data processing itself. A system operating exactly as designed can still harm people, through over-collection, unauthorized profiling, or misuse of their data.

So the plan works from a different toolkit. It aligns the system's privacy objectives with the organization's mission and risk tolerance, and frames requirements around the privacy engineering objectives — predictability, manageability, disassociability — and the Fair Information Practice Principles. It describes how the organization handles problematic data actions and honors data subject rights such as access, correction, and deletion.

Its inputs are the privacy program's working artifacts: legal and regulatory obligations, the privacy impact assessment and privacy risk assessment, information exchange agreements, and public notices such as a SORN. For MCMS, full of benefit-case PII, Tom reads this plan the way Karen reads the security plan.

MCMS, like most modern systems, is largely assembled from other people's work — commercial products, cloud services, support contracts. The C-SCRM plan is where that risk becomes visible. It applies the organization's overarching supply chain risk management strategy to this one system, across the component life cycle: design, manufacturing, acquisition, delivery, integration, operations, and disposal.

Its distinctive contents follow from that job. It inventories the system's suppliers and components and rates their criticality. It names the people filling supply chain roles. It describes how supply chain risks are continuously evaluated and monitored, with response strategies and the justification for mitigations taken. And it documents relationships with key suppliers — roles, expectations, performance management, and governance.

SP 800-161 is the companion publication; its overlay of SP 800-53 controls carries the control-level guidance. When the file-scanning vendor swaps subcontractors, this plan is where that ripple lands as recorded, decision-ready risk information.

Now the structural decision every organization makes: keep three separate plans, or one consolidated system plan? Rev 2 explicitly allows either. In a consolidated plan the common elements — system name and identifier, operational status, system overview, authorization boundary description — appear once, so every reader gets the same picture of mission, purpose, and environment, and the security, privacy, and supply chain functions collaborate around one record.

Consolidation wins when one team maintains everything, the readers overlap, and duplication is the main failure mode. Three separately maintained copies of the boundary description will drift apart; the only question is when.

Separation wins when different officials own different review cycles — Tom's privacy reviews don't run on Karen's calendar — or when access needs differ, since supplier details may warrant tighter handling than general security posture. Either way, the elements themselves are identical. Structure is presentation; the information obligations don't change.

Lesson 3 — What Changed in Revision 2 (~8 min)

Twenty years between revisions — exactly what moved, and why your templates care.

Spot 2006-era language and structure in a legacy plan and modernize it to Revision 2.

Dana inherits MCMS's oldest artifact: a security plan last rebuilt in 2019, opening with the sentence 'This General Support System serves the agency's case processing mission.' A colleague offers a quick fix — find and replace the old terms, update the date, done by Friday.

Would you take that deal? The terms are only the visible problem. General support system was retired from OMB Circular A-130 a decade ago, and SP 800-18r2 follows suit. But deprecated language usually travels with deprecated structure: a 2006-shaped narrative, one plan where three lenses belong, elements no RMF task keeps current.

This lesson is the delta map — what actually changed between the 2006 edition and Revision 2 — so you can tell a cosmetic fix from a structural rebuild, and know which one a legacy document needs.

Rev 1, published in 2006, was a guide for developing one document: the security plan for a federal information system. Rev 2, final in June 2026, supersedes it with four structural shifts.

First, one plan became three. The publication now defines the full triad — security, privacy, and C-SCRM — grounded in the RMF, SP 800-161, and the NIST Privacy Framework, with an explicit option to consolidate. Second, the narrative template became a set of plan elements correlated to RMF tasks. Each element's source is a specific task input or output, mapped in Appendix A, which makes the plan a product of doing RMF rather than a parallel paperwork exercise.

Third, documents became data. A whole section, §3.3, covers information management tools, automated collection, dashboards, machine-readable formats, and protecting plan information — none of which had a 2006 counterpart. And fourth, repetition became reference: technical content from other NIST publications is now included by pointer, so the plan guidance can't drift out of sync with its sources.

Two terminology changes will touch nearly every legacy plan you review. The first is a retirement: general support system, major application, and minor application are gone, for consistency with OMB Circular A-130, which dropped them in its 2016 revision. Everything is simply a system now. Scoping questions are answered by the authorization boundary, not by a taxonomy of application sizes.

The second is a rename with substance behind it: system boundary becomes authorization boundary, for consistency with SP 800-37. The boundary that matters for planning is the one that scopes the authorization — all components and subsystems to be authorized for operation.

So when the MCMS plan opens with 'This General Support System…', Dana reads it as a signal, not a typo. The document predates current A-130 language, and it has earned a structural review — not a find-and-replace.

You don't rebuild a legacy plan from a blank page. Rev 2 ships with supplemental materials — outline examples showing ways to combine the plan elements into a traditional artifact or an automated system plan report. There are four: a system security plan outline, a system privacy plan outline, a C-SCRM plan outline built on SP 800-161, and an updated roles and responsibilities supplement for system plans.

The publication is explicit that these are starting points. You define the methods, structures, and formats, and you add organization- or system-specific elements as needed. The outlines are a floor to build on, not a ceiling to comply with.

They're also deliberately element-structured, which is quiet good news for modernization: the same outline that renders as headings in a document maps cleanly onto fields in a GRC tool. Dana's rebuild of the 2019 plan can start from the official outline and land directly in the agency's repository.

Lesson 1 — Elements That Describe the System (~9 min)

Who and what this system is — settled cleanly, before a single control is discussed.

Author the describing elements — identity, overview, boundary, inventory — from RMF task outputs, written for their real readers.

Karen returns Dana's draft plan with one sentence flagged — the System Overview. It reads: 'MCMS is a three-tier application leveraging containerized microservices behind the agency enterprise service bus.' Her note in the margin: 'I read this twice and I still don't know what MCMS does or who depends on it.'

The overview isn't wrong. It's written for the wrong reader. The describing elements of a system plan exist so that leadership, risk managers, and system personnel can all answer the basic questions — what is this system, what does it do, for whom, within what boundary — without calling a meeting.

This lesson is about authoring those describing elements well: where each one comes from, who it serves, and what good looks like. By the end, you'll rewrite that overview so Karen approves it on the first pass.

Here's the design insight that organizes everything in Rev 2's §3: plan elements are not invented for the plan. Table 1 lists each element alongside the RMF tasks that produce and update it, and Appendix A maps the correlation task by task. Registering the system produces the name and identifier. Categorization produces the impact levels. Selection produces the planned control implementations.

That means Dana's job is placement and upkeep, not creative writing. When an RMF task completes, its output lands in the matching plan element — and when a later task changes that output, the element changes with it. The plan stays current because the process feeds it, not because someone remembers to edit a document.

The figure shows the whole element set in two broad clusters: elements that describe the system — identity, overview, boundary, inventory — and elements that track risk decisions, from categorization through authorization. This lesson takes the first cluster; the next lesson takes the second.

Five elements settle the system's identity. The System Name and Identifier comes from system registration, RMF task P-18 — the unique key every other record points at. The System Type says what kind of system this is. The System Overview describes the mission processes and business functions the system supports — the element Karen flagged, and the one most often written for engineers when its readers are decision-makers.

Role Identification and Responsible Personnel, from task P-9, names the authorizing official, the system owner, and the other roles with responsibilities for the system; Rev 2's roles and responsibilities supplement is the companion reference. And System Information Types, from tasks P-12 and P-13, records what information the system creates, processes, stores, and transmits — the direct input to categorization.

Notice what these have in common: none requires a security judgment. They require accuracy. Get them right once, keep them current, and no downstream argument — about categorization, scope, or assessment — ever has to re-litigate what the system is.

Four more elements establish scope. Laws, Regulations, and Policies Affecting the System Requirements records the obligations that shape requirements — for MCMS, the Privacy Act enters the plan here, long before any privacy control is selected. The System Component Inventory lists the components inside the boundary, and Environment of Operation Diagrams depict the architecture clearly enough that a reader can see how the pieces connect.

The heavyweight is the Authorization Boundary Description. It defines the scope of the system's protections — all components and subsystems to be authorized for operation. It decides what the categorization covers, what the assessor tests, and what Karen signs for. Table 1 gives it five source tasks, including Monitor's M-1, because boundaries change while systems operate.

Cloud inheritance is what makes it subtle. MCMS inherits platform controls from the agency's cloud environment, so the boundary description must say precisely where MCMS ends and the platform begins. Vague words here don't stay harmless; they resurface as scope disputes at the worst possible time.

Watch Dana author the two describing elements that get read the most. First, the System Overview, rewritten for its actual audience: 'MCMS tracks federal benefit case files from intake through determination, roughly 40,000 cases a year. Caseworkers in all ten regional offices depend on it daily; an outage halts benefit processing. It stores names, addresses, Social Security numbers, and case histories — PII for about 300,000 individuals.' Three sentences: what it does, who depends on it, what it holds. Karen can read that in thirty seconds and know what's at stake.

Next, the Authorization Boundary Description: 'The MCMS authorization boundary includes the case management application, its database, and the interface services that exchange data with the eligibility system. It excludes the agency cloud platform, which is separately authorized; MCMS inherits physical, network, and hypervisor controls from that platform's common control package. One external connection crosses the boundary — the nightly feed to the benefits payment system — and is documented in the Information Exchanges Summary.' Inside, outside, and the crossings: every scoping question an assessor will ask, answered in three sentences.

Notice that neither element mentions a single control. That's the discipline of the describing cluster — establish what the system is so cleanly that every later risk conversation can stand on it.

Lesson 2 — Elements That Track Risk Decisions (~9 min)

Categorization to authorization — plus the records that prove the plan lives.

Maintain the elements that carry categorization, implementation, assessment, and authorization state, and write records that prove plan currency.

The annual assessment report for MCMS lands in Dana's queue: two access control weaknesses, written up with recommendations. Marcus, the system owner, suggests keeping the findings in the assessor's report 'so the plan stays clean for Karen.'

Decide before reading on: does the plan stay clean, or does it take the findings? Rev 2's answer is unambiguous — and it is the opposite of clean. The plan is the running record of the system's risk state, and that state now includes two known weaknesses with remediation under way.

This lesson covers the elements that carry that record: categorization, control implementation, statuses, exchanges, decisions, and the review and change records that prove the plan is being kept alive. These are the elements leadership actually checks between authorizations.

Two heavyweight elements anchor this cluster. System Categorization, from tasks C-2 and C-3, records the impact level for each security objective — confidentiality, integrity, availability — for every information type the system handles, with the system's overall category set as the high-water mark. It's the element that sets the stakes for everything after it.

Control Implementation Details is the largest element in the plan: implementation details for all controls allocated to the system, plus the location of referenced artifacts. Look at its source-task list in Table 1 — Prepare, Select, Implement, Assess, Authorize, and Monitor tasks all feed it. It accretes through the entire framework and never stops changing.

The craft standard is the one from the SP 800-53 course: describe what this system in this organization actually does — the procedure, the configuration, the integration — not a restatement of control text. Rev 2 adds a data discipline on top: reference artifacts by location, so each detail stays navigable when it's a field in a repository rather than a section in a document.

The rest of the cluster reads like the plan's scoreboard, in life cycle order. System Plan Approval records the AO's approval at task S-6 — an element, not an email thread. Control Implementation Status tracks each control's state as planned implementations become real. The Information Exchanges Summary documents the flow of information with systems outside the authorization boundary — MCMS's nightly payment feed lives here.

After assessment, Control Assessment Status carries the per-control results, and Remediation Actions carries the weaknesses being fixed, with the associated POA&M. Those two access control findings from the opener belong in these two elements — visible, owned, and tracked, not parked in a report.

Then the decisions. The System Authorization Decision element records Karen's decision, its effective date, and its duration. System Operational Status says whether the system is operating, under development, or disposed of. One element is explicitly optional in Table 1 — the Digital Identity Acceptance Statement, per SP 800-63. Everything else is the expected information baseline.

Two last elements answer the oldest complaint about system plans — beautiful the day they were signed, never touched again. System Plan Review Records log each periodic review: when it happened, who performed it, what it covered. System Plan Change Records log each change: what changed, why, and when. Both are common to all three plan outlines.

Together they turn 'living document' from a slogan into evidence. An auditor, an assessor, or an incoming ISSO can open the records and see the plan's pulse — reviews happening on rhythm, changes recorded as they occurred, nothing reconstructed from memory the week before an audit.

They also change the psychology of maintenance. When every review is expected to leave a one-line record, reviews actually happen. What gets recorded gets done.

Here's what those records look like when Dana writes them — unglamorous on purpose. A review record: '2026-06-12 — Quarterly review by D. Okafor, ISSO. Scope: boundary description, information exchanges, open remediation actions. Result: no changes required; two POA&M items on schedule.' Date, reviewer, scope, result. One line, sixty seconds to write, and the plan's currency is now provable.

A change record from the same quarter: '2026-05-03 — Authorization Boundary Description and Information Exchanges Summary updated for the file storage migration; environment diagrams revised. Trigger: platform change notice PCN-2214. Accepted by: M. Hill, system owner.' What changed, why, what triggered it, and who accepted it.

Compare that with the line Dana inherited from 2019: 'Reviewed — no comment.' Undated, unsigned, unscoped — it proves nothing, and an assessor treats it as nothing. The standard is modest: every record answers when, who, what, and why. These lines are the evidence that the living document actually lives.

Lesson 1 — Plans as Data (~8 min)

Rev 2's quiet revolution: the plan is information in a repository, not prose in a binder.

Apply §3.3's guidance to collect, share, manage, and protect plan information with automation.

Karen's request arrives Tuesday: 'Briefing on MCMS's current posture. Thursday. Thirty minutes.' Dana opens the most recent plan document — a 214-page PDF exported eleven months ago. The boundary section predates the storage migration. Four POA&M items have closed since; two new ones have opened. The PDF was stale the day it was exported.

The old playbook is a scramble: two days assembling a special data call, emailing teams for current numbers, pasting them into slides nobody will ever reconcile with the plan.

Rev 2 describes a different way to live. Section 3.3 treats plan information as data in a central repository — collected automatically, current by default, rendered into documents only when someone needs one. This lesson is that playbook.

Rev 2 encourages automating the collection of system information using information management tools with a central data repository, and it names the categories: GRC, SOAR, and SIEM platforms. Automation can capture control implementation status to demonstrate ongoing risk management, track POA&M activities so remediation actually completes, support plan reviews, and control access to plan information.

Collection rides on sources the organization already has — component inventories, personnel directories, detected information types, changes to common and hybrid controls, POA&M state. The point isn't new data; it's existing data flowing into plan elements without a human retyping it.

The publication is practical about resources: organizations that can't run a dedicated platform can manage plan information with commercial or open-source tooling. The discipline matters, not the product. And one footnote is worth knowing — OSCAL's implementation layer includes a system security plan model, the standard machine-readable format for exactly this shift.

A repository earns its keep when each reader gets the right slice. Senior leaders view risk posture across every system in the organization. Karen and Tom jump straight to the elements they need for continuous monitoring and ongoing authorization. System personnel track approvals and control metrics. Statuses can be shared with interconnected systems, with systems inheriting common controls, and with approved external partners. Assessors get scoped access — enough to enter results and artifacts directly, not the keys to the whole repository.

On the management side, the tools track changes to elements, feed continuous monitoring reporting, and alert leadership when information turns inconsistent. And when someone needs a traditional plan document, the tools generate one from an organization-approved template.

That last capability quietly inverts the old world. The document becomes an output of the data — a render, produced on demand — instead of the source of truth that everything else struggles to keep synchronized.

One caution completes the picture. Aggregated plan information describes exactly how a system is defended — its architecture, its controls, its known weaknesses, its responsible people. In an adversary's hands, that is a targeting package.

So §3.3.4 closes the loop: protecting plan information is itself part of the security posture. Access to the repository is controlled and audited like the sensitive asset it is, and sharing follows deliberate rules rather than convenience.

Held together, the four practices — collect automatically, share by role, manage as data, protect the aggregation — are what let Dana answer Thursday's briefing from a live dashboard instead of a stale export. That's the plan working as Rev 2 intends: current, decision-ready, and safe.

Lesson 2 — From Draft to Approval (~8 min)

S-4 and S-6 are where the plan becomes a commitment rather than a draft.

Take the plan from RMF task outputs to AO approval at S-6 — and defend why approval precedes assessment.

Planning the MCMS reauthorization, Marcus proposes a schedule that 'saves six weeks': book the assessors now, run the assessment, and have Karen approve the updated plan afterward. 'She'll want to see assessment results before signing anything anyway.'

Dana turns it down. Would you? The RMF puts plan approval at task S-6, the end of the Select step — before Implement, before Assess. That ordering isn't bureaucratic sequencing. It changes what the assessment is.

This lesson walks the plan from RMF task outputs to the AO's signature: what Prepare and Categorize contribute, what Select builds, and what Karen's approval at S-6 actually asserts — and why it has to come before anyone tests anything.

Section 4 of Rev 2 walks the plan through the framework, and the figure shows the whole journey. In Prepare, the describing elements fill from task outputs — stakeholders, information types, boundary, inventory, diagrams. In Categorize, the impact levels land in the plan along with their review and approval.

Select is where the plan grows most, and it ends at the hinge — task S-6, plan review and approval — after which the plan stops being a draft and becomes a commitment. Everything past that hinge, from Implement through Monitor, both reads the plan and writes back into it.

Keep the shape in mind as a loop, not a line. A system plan is drafted once, approved each authorization cycle, and updated for as long as the system exists. The next two screens zoom into the two moments this lesson is about: Select's documentation work, and the approval itself.

In Select, the plan accumulates the control story. Task S-1 records which controls are selected. Task S-2 documents tailoring — organization-defined parameter values and scoping decisions written into the plan, so the record shows not just what was chosen but how it was adapted, and why. Task S-3 allocates controls as system-specific, hybrid, or inherited from common control providers.

Then S-4, the plan's biggest single task: documentation of planned control implementations. Every allocated control gets a planned implementation description — the 'how MCMS will meet this' text that assessors will later test against and that Implement will later make true.

The system-level continuous monitoring strategy enters here too, at S-5: which controls get watched, how often, and by what means — the machinery that ongoing authorization will later rely on. By the end of Select, the plan is a complete, testable protection story. On paper, deliberately.

At S-6, the authorizing official — or a designated representative — reviews and approves the plan, and the approval is recorded in the System Plan Approval element. The approval asserts something specific: the protections as described, if implemented as described, are adequate for the risk the system presents.

That's why approval precedes assessment. The assessor's question is 'is the system implemented as the approved plan describes?' Reverse the order and the question dissolves — you'd be assessing against a target nobody has committed to, and negotiating adequacy after paying for the test.

For Dana the ordering is also practical wisdom. Karen's early approval on the plan surfaces disagreements about adequacy while they're cheap to fix — a boundary argument at S-6 costs a meeting; the same argument after assessment costs a re-assessment. Marcus's six-week saving would be repaid with interest.

Lesson 3 — Keeping the Plan Alive (~9 min)

Approval is the beginning of the plan's life, not the end.

Wire plan updates into events — changes, assessments, decisions — so the AO can always decide from current information.

A platform change notice lands in Dana's queue: MCMS's file storage migrates to a new cloud object storage service this month. A data flow that crosses the authorization boundary will change. The plan's boundary description, exchange summary, and environment diagrams will all be out of date the day the migration completes.

Marcus suggests logging it in a ticket and batching all plan updates for the next reauthorization, two years out. It's one line in a tracking system versus an afternoon of element updates — and nobody reads the plan between authorizations anyway. Right?

Everything in this final lesson argues otherwise. After approval, every RMF step writes back into the plan — and the moment updates start waiting for reauthorization, every decision in between is made on stale information. Here's how the plan stays alive, step by step.

In Implement, the plan's words converge on reality. As controls are built, tasks I-1 and I-2 turn planned implementation descriptions into as-implemented descriptions. Where reality forced a different approach than the plan described, the description changes to match reality — with a change record — because the plan documents what is, not what was hoped.

In Assess, the assessor tests against the approved plan, and the results flow straight back into it. The outputs of tasks A-5 and A-6 update the Control Assessment Status element, and every weakness enters the Remediation Actions element with its POA&M — owned, scheduled, visible.

Notice the pattern that repeats in every remaining step: the task consumes plan information, produces a result, and the result lands in a named element. No side files, no shadow spreadsheets. The plan is the record.

In Authorize, the plans travel in the authorization package to Karen's desk, and her decision — with its effective date and duration — is recorded in the System Authorization Decision element. The plan carried the risk picture in; the decision comes back into the plan.

Monitor is the long tail where plans live or die. Task M-1 flows system and environment changes into the boundary, overview, and implementation elements — Dana's storage migration is exactly this. M-2's ongoing assessments refresh the status elements. M-4 keeps the plan information in the authorization package current, which is what makes ongoing authorization possible: Karen relies on continuously current information instead of waiting for a periodic reauthorization. And a significant change — one that substantially affects the system's risk — triggers deliberate re-evaluation, not a silent element edit.

At the very end, M-7 records disposal in the operational status element, and the plan closes the loop on the system's whole life.

The test of a living plan is simple and a little brutal: could Karen make an informed decision from it today, without a special data call? If yes, the plan is alive. If the honest answer is 'after we update a few things' — it isn't, and every day extends the gap.

Rev 2's whole design serves that test. Elements sourced from RMF tasks mean updates arrive with the work. Review and change records make the rhythm provable. Automation makes currency the default instead of a heroic effort.

So the migration notice from the opener gets its real answer: update the boundary, exchanges, and diagrams now, record the change, and the plan keeps telling the truth. That's the habit this whole course was building toward.

Where you started: a plan as shelf paperwork. Where you've landed: system plans as the living, decision-ready record of one system's protections — a security plan, a system privacy plan, and a C-SCRM plan, consolidated or separate, answering three risk questions about one system.

You can author the elements: describing elements that settle identity and scope, decision elements that carry categorization through authorization, and the review and change records that prove the plan's pulse. You can run the plan through the RMF — drafted from task outputs, approved at S-6 before assessment, and written back into by every step after. And you can treat the plan as data: collected automatically, shared by role, protected like the targeting package it would be in the wrong hands.

Dana's job, done well, is quiet: the plan is simply always right. From here, the SP 800-53 course teaches the control catalog those implementation details draw from, and the RMF course walks the full framework the plan lives inside.