RMF Prepare step tasks before control selection

What the RMF Prepare step asks for before NIST 800-53 controls are selected

When a contract, customer or agency requires NIST SP 800-53 under the Risk Management Framework, the first step is not choosing controls. Prepare is the step that readies the organization and the system before any control is selected, and under SP 800-37 Rev. 2 it contains seven organization-level tasks (P-1 to P-7) and eleven system-level tasks (P-8 to P-18). The organization-level tasks cover key roles, risk management strategy and risk tolerance, organization-wide risk assessment, tailored baselines or CSF Profiles, common controls, prioritization of systems by impact level and an organization-wide continuous monitoring strategy. The system-level tasks cover mission and stakeholders, the authorization boundary, information types, a system risk assessment, security and privacy requirements, enterprise architecture placement and registration.

Cost and duration depend on how many systems are in scope, how many common controls the organization can share across them, and how much current documentation already exists, such as network diagrams, data flow records and an asset inventory. No cost or timeline figure is supplied for this step, so ask any provider to price it from a written scope that lists the systems, the number of organization-level decisions still open and the documents that must be created or updated. Also ask whether the work is one-time or recurring, since the monitoring strategy and registration records must be maintained after the first pass.

The organization owns every task and decision. The authorizing official is primarily responsible for the authorization boundary under Task P-11, and the system owner registers the system under Task P-18. An implementation partner can draft the inputs, such as the boundary diagrams, the requirement allocations and the continuous monitoring plan, but it cannot set risk tolerance, accept risk or define the boundary on the organization's behalf. Confirm the exact task wording and outputs in NIST SP 800-37 Rev. 2 before writing a statement of work, and assign a named owner to each task before any control is chosen.

Which seven organization-level Prepare tasks set up the program

Before any system is considered, SP 800-37 Rev. 2 asks the organization to build the governance that every later authorization depends on. The seven organization-level tasks produce roles, risk decisions, tailored baselines, shared controls, system priorities and a monitoring strategy, and a reviewer can check each one by asking for a named output.

Assign key roles (P-1)

This task names who holds each RMF role across the organization, including the senior accountable official, the risk executive, the authorizing officials and the control assessors. A reviewer will ask for signed appointment letters or role descriptions that show who can accept risk and who must stay independent of the assessment. Check that no one holds both the assessor and the decision role for the same system.

Set risk strategy and tolerance (P-2)

This task records how the organization frames risk, what level of risk it will accept and how risk decisions move up the chain. The output a reviewer expects is a written risk management strategy with an explicit risk tolerance statement approved by senior management. Without it, individual authorizing officials have no stated baseline against which to judge their own decisions.

Assess organization-wide risk (P-3)

This task looks at threats and vulnerabilities that affect the organization as a whole, not one system at a time. Its output is an organization-level risk assessment that shows shared threat sources, common weaknesses in supplier services and enterprise dependencies. Ask whether the results feed the tailoring decisions in P-4 and the system risk assessments that follow.

Publish tailored baselines or CSF Profiles (P-4)

This task produces the organization's tailored control baselines, or Cybersecurity Framework Profiles, that link the RMF to the NIST Cybersecurity Framework. The output a reviewer will ask for is a published baseline document that records each added, removed or modified control and the reason for it, starting from the SP 800-53B baselines. Confirm that the document is version controlled and that systems cite it when they select controls.

Identify common controls (P-5)

This task identifies controls that are implemented once at the organization level and can be inherited by many systems, such as physical security of data centers or enterprise identity services. The output is a common control catalog that names each provider, the controls covered and the documentation the provider must share. Check that the inheritance claims in system plans match this catalog exactly.

Prioritize systems by impact (P-6)

This task ranks systems that share the same impact level so that the organization can sequence authorizations and assessments. The output is a prioritized list grouped by impact level, with the reasons for the order, such as exposure, mission criticality or upcoming contract dates. Ask whether the list is reviewed when a system's categorization or mission changes.

Set continuous monitoring strategy (P-7)

This task defines how the organization will monitor controls across all systems after authorization, including the frequency of assessments, the metrics reported and the people who review the results. The output a reviewer will ask for is an organization-wide continuous monitoring strategy that system-level monitoring plans must follow. Confirm that the strategy names who receives monitoring reports and how changes trigger reassessment.

How system-level Prepare tasks define the system before selection

The system-level Prepare tasks, P-8 through P-18 in SP 800-37 Rev. 2, decide what the system is before anyone picks a control. The first tasks identify the missions the system supports, the stakeholders who depend on it and the assets it holds. Those answers matter because they set the impact of loss and the parties who must accept risk. The most consequential decision is the authorization boundary under P-11, which the authorizing official is primarily responsible for determining. Everything inside the boundary is in scope for control selection, and anything outside it is either excluded or handled as an inherited or external service. Design documentation and network diagrams are the inputs, so a boundary drawn from an outdated diagram will produce a control set that does not match the real system.

Next, the information types and their life cycle (creation, processing, storage, transmission and disposal) determine which data the controls must protect and where. A system-level risk assessment then tests how threats to those missions and assets could exploit the system as scoped, and its findings feed the definition and allocation of security and privacy requirements. This is where a team decides which requirements the system owner must meet directly and which can be satisfied by a common control provider or a cloud platform. Confirm with your authorizing official how inheritance will be documented before you allocate requirements, because an undocumented inherited control is often treated as a gap at assessment.

The last tasks place the system in the enterprise architecture and register it with the organization's program or management offices under P-18, which the system owner carries out. Registration tells the organization what the system is and what security and privacy implications it carries, and it supports posture reporting. Ask your program office which registration fields and architecture artifacts it requires, and keep them consistent with the boundary and information type decisions made earlier. Changes to any of these inputs should trigger a review of the selected baseline, not a silent update to the system record.

How the authorization boundary and system registration are set

This sequence turns a system idea into a documented scope of protection that the authorizing official has agreed to manage and a registration entry the organization can report against. Both outputs must exist before control selection begins.

Confirm the system owner and mission context
The system owner, with the mission or business owner, confirms what the system is for, who relies on it, and which stakeholders must sign off on its scope. The owner records these answers in a short system description that the rest of the sequence builds on. Done means every named stakeholder has been identified and the system description is dated and version-controlled.
Gather design documentation and network diagrams
The system owner collects the inputs the authorizing official will rely on: architecture and design documents, data flow diagrams, network diagrams, hosting and tenancy details, and lists of interconnected systems. For a self-hosted open-source platform, this usually covers the cluster or virtual machine layout, ingress and egress paths, identity sources, backup targets and management networks. Done means each diagram names its version, date and owner.
Draft the boundary diagrams and component inventory
A technical team, which may include an implementation partner, drafts the diagrams and a component inventory from the design documents and checks them against the running environment. The draft shows every component that stores, processes or transmits the system's information, plus the external services and shared platforms it depends on. Drafting is preparation only: the team does not decide what belongs inside the boundary. Done means the draft has been reviewed by the system owner and the people who operate the environment.
Determine the authorization boundary
The authorizing official makes the boundary determination under Task P-11, deciding which components, services and people fall within the scope of protection the organization agrees to manage. The decision is theirs to make and cannot be delegated to a contractor, assessor or platform team. The output is a signed boundary record that states the included components, the excluded interconnections and the reason for each exclusion. Done means the record is approved and filed with the system security documentation.
Document interconnections and inherited services
Once the boundary is fixed, the system owner records each interconnection that crosses it, including identity providers, logging destinations, shared hosting platforms and any services that will provide controls to the system. Where a control will be inherited from a common provider, the provider's documentation is referenced here so later control selection can rely on it. Done means every crossing point has an owner, a data flow description and a stated trust relationship.
Register the system with the program or management office
Under Task P-18, the system owner submits a registration to the organizational program or management office. The entry describes the system, its mission, its expected security and privacy implications and its boundary reference, and it lets the organization report posture across its portfolio. Done means the office has acknowledged the entry and the registration identifier is recorded in the system security plan.
Publish the boundary record and registration entry
The sequence closes with two artifacts that later tasks depend on: the signed boundary record with its diagrams and interconnection list, and the registration entry with its identifier. The system owner stores both under version control, links them from the system security plan, and confirms that the authorizing official and the program office hold current copies. Done means a reviewer can trace every control decision back to a documented boundary.

Tailored SP 800-53B baselines or CSF Profiles: which to publish

SP 800-53B defines three security control baselines matched to system impact level. The organization can publish its own tailored version of these baselines during Prepare, so systems of the same impact level start from one agreed control set instead of negotiating controls system by system. The OSCAL profiles for SP 800-53B Release 5.2.0 select 149 items for the low baseline, 287 for moderate and 370 for high, counting base controls and enhancements together.

Starting point: Use the baseline that matches the impact level set during categorization, then tailor it rather than building controls from scratch.
Tailoring: Remove or adjust controls that do not fit the organization's technology, and document each change with its rationale.
Overlays: Add a published overlay where a specific technology or mission requires controls the baseline does not cover.
Organization-level output: The tailored baseline is the document P-4 asks for, so it should be approved and versioned like any governing standard.
Scope limit: Baseline counts describe the OSCAL profile selections only, not the effort needed to implement or assess them.

Confirm with your authorizing official or governance body which impact levels the organization uses before publishing any tailored baseline.

Which Prepare outputs an assessor will ask to see

This table maps each major Prepare output to the role that owns it and the evidence an independent assessor would typically ask to review. Read it as a checklist of documents to have ready before control selection begins, and confirm the exact review expectations with your assessor, since no assessor's checklist is implied here.

Prepare output	Who owns it	Evidence an assessor would request
Risk management strategy and risk tolerance	Senior leadership, with the CIO and risk executive	Signed strategy document, stated risk tolerance, and records showing how it was approved and communicated
Organizationally tailored baselines or CSF Profile	Risk executive and security lead	Published baseline or Profile, tailoring rationale for each change, and the version history showing the approval date
Common control list	Common control provider or platform owner	Inventory of controls provided at organization level, inheritance designations, and the responsible party for each control
Authorization boundary record	Authorizing official determines, system owner documents	Boundary statement, design documentation, network diagrams, and a component inventory that matches the boundary
System registration	System owner, with the program or management office	Registration record in the organizational inventory showing mission, owner, impact context and expected security implications
Continuous monitoring strategy	Organization-wide program owner, with system owners applying it	Documented strategy, defined monitoring frequencies, named reporting owners, and records of recent monitoring activity

Who owns the Prepare decisions and who prepares the inputs

The Prepare step leaves no room for ambiguity about who decides. The organization owns the risk decisions, and the authorizing official is the person who accepts that risk. Under SP 800-37 Rev. 2, the authorizing official is primarily responsible for determining the authorization boundary (Task P-11), which sets the scope of protection the organization agrees to manage. The organizational tasks P-1 to P-7, such as setting risk tolerance and publishing tailored baselines or CSF Profiles, belong to senior leadership and the risk executive, not to an outside partner. The system owner then registers the system with the organization's program or management offices under Task P-18, so the organization knows what it runs and what its security implications are.

An implementation partner such as DeployOpen works on the inputs to those decisions. In the client's own cloud accounts, data centers or air-gapped networks, the partner can draft the mission and information-type descriptions, the system-level risk assessment, the network and data-flow diagrams that support the boundary decision, and the evidence drafts that the system owner reviews before anything goes to the authorizing official. Every draft is marked as a draft, and the client's staff approve, edit or reject it. The client should confirm in writing which documents the partner will draft, who signs each one, and which items remain entirely internal.

Only an independent assessor or auditor issues assessment results. DeployOpen prepares systems, documentation and evidence for that assessment, but it does not issue assessment reports, authorizations, certifications or any statement that a control is satisfied. Ask any prospective partner to state this boundary in the scope document, and check that the assessor who will test the system is independent of the team that built it. Where the assessor is also expected to review the boundary decision, confirm early with the authorizing official and the assessor how that review will be recorded.

What usually delays Prepare and how to avoid it

Most delays in the Prepare step come from decisions that were postponed rather than from technical difficulty. The six pitfalls below cluster around three questions: what is inside the system, who decides, and what evidence will be needed later. Each card names the check that prevents the delay.

Unclear authorization boundary

The authorizing official is primarily responsible for fixing the authorization boundary under Task P-11, and it defines the scope of protection the organization agrees to manage. If components such as shared logging, identity services or backup repositories sit on the edge, assessors and the authorizing official will argue about ownership late in the process. Fix: agree the boundary in writing, with each component named as inside, outside or inherited, before any control is selected.

No current network diagram

Task P-11 uses design documentation and network diagrams as inputs, so a diagram that predates the last migration undermines the boundary and every later inventory. Teams often discover unlisted hosts, service accounts or cross-boundary data flows only when an assessor walks the environment. Fix: regenerate the diagrams from the live environment and reconcile them against the asset inventory before the boundary review.

Unclear roles and decision rights

Prepare assigns key roles at the organization level, and several of them, including the authorizing official and the system owner, carry decisions that cannot be made by someone else. When these roles are unnamed, tasks stall while people wait for sign-off that nobody is empowered to give. Fix: publish a named role assignment for the authorizing official, system owner and control assessor, with each person's decision authority written down.

Tailoring decisions made late

Tailored baselines and CSF Profiles are published as organization-level outputs of Task P-4, and selecting controls before they exist forces teams to re-select later. A late tailoring decision can add or remove dozens of controls in a system already partly implemented. Fix: publish the organizationally tailored baseline or CSF Profile first, and treat any system-level deviation as a documented exception.

Inheritance not documented

Where a system relies on a common control provider or a cloud platform, the inherited controls must be identified as common or hybrid, and the provider must supply the documentation that shows they work. Without that, the system owner cannot describe which controls are actually theirs. Fix: request the provider's control documentation and inheritance statements during Prepare, and record each inherited control's source.

Monitoring strategy left until after authorization

The organization-wide continuous monitoring strategy is one of the Prepare outputs, yet teams often draft it after the authorization decision to satisfy the ongoing review. A system authorized without a defined monitoring cadence has no basis for reporting posture or significant change later. Fix: define the monitoring frequency, scanning scope and reporting owner as part of Prepare, so the authorization package already includes them.

Questions buyers ask about the RMF Prepare step

How long does the RMF Prepare step take?

No duration is supplied for Prepare, so no timeline can be quoted here. The elapsed time depends on how much of the organization-level work already exists. If the organization already has a risk management strategy, assigned key roles and published tailored baselines, Prepare for a new system is mostly system-level work: confirming the mission, stakeholders, information types, authorization boundary and registration. If none of the organization-level tasks exist, those come first and can take longer than the system work. Ask any provider for a written milestone plan that separates organization-level and system-level tasks, and ask which inputs, such as design documentation and network diagrams, must be ready before the work begins.

Can an organization run the RMF Prepare step in-house?

Yes, Prepare is an organizational activity, and the organization owns every decision in it. The tasks assign key roles, set risk tolerance, determine the authorization boundary and register the system, and these outputs must come from the organization's own officials. The authorizing official is primarily responsible for determining the authorization boundary, and the system owner registers the system. In-house teams usually struggle with the organization-wide tasks because they require agreement across the CIO, risk, privacy and mission functions, and with the boundary decision because it sets what the organization agrees to protect. An outside partner can prepare the diagrams, inventories and draft documents, but the decisions stay with the organization.

What does the RMF Prepare step cost, and who gets paid?

NIST does not estimate certification or compliance costs, so no figure is given here. The cost comes from staff time and any outside help. Internal costs cover the authorizing official, CIO, system owner, privacy and risk staff who attend decisions and approve documents. External costs, if used, cover people who build the inventories, diagrams, risk assessment and draft plans. Most of the Prepare work is one-time for a given system, while the risk strategy, roles and tailored baselines are organization-wide and are reviewed periodically. Costs rise with the number of systems, the number of boundaries, the state of existing documentation and the number of stakeholders who must agree. Ask any provider for a fixed-scope quote that lists deliverables, assumptions and the documents the organization must supply.

Can a partner take over the RMF Prepare step?

A partner can do much of the preparation work but cannot own the decisions. Suitable outsourced work includes gathering asset inventories, drafting the system description, mapping information types, producing network and data-flow diagrams, drafting the organizationally tailored baselines and assembling registration material. Decisions that stay with the organization include risk tolerance, the choice of authorizing official, the authorization boundary and any acceptance of risk. DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure and prepares systems and evidence for assessment, but it does not issue authorizations or assessment reports. Any independent assessor must also remain separate from the people who prepared the system to avoid conflicts of interest.

What must the organization provide before Prepare starts?

The organization must provide the people and documents that the tasks depend on. Before the system-level tasks begin, the team needs the system's mission and business owners, a list of stakeholders, asset inventories, design documentation, network diagrams, data flows and the information types the system handles. For the organization-level tasks, it needs named key roles, a risk management strategy, a stated risk tolerance and any existing security or privacy programs that can be reused. Access to the target infrastructure, such as cloud accounts, data centers or air-gapped networks, is also needed so that the boundary can be checked against what actually runs. Ask a provider to list these inputs in the written scope so that gaps are visible before any work is billed.

Does the RMF Prepare step produce an authorization to operate?

No. Prepare produces the organizational and system foundations that the later steps depend on, such as roles, tailored baselines, the authorization boundary, a system-level risk assessment and registration. An authorization to operate is a separate decision made after Select, Implement and Assess, when the authorizing official accepts the residual risk. Prepare outputs help the authorization package but do not replace it. Teams sometimes treat a completed Prepare checklist as proof of authorization, which leads to rework when assessors find that the boundary or baseline was never agreed. Confirm with the authorizing official which Prepare outputs they expect to see before the Select step begins.

How DeployOpen prepares systems and evidence for the Prepare step

DeployOpen helps organizations prepare the systems, documents and evidence that the Prepare step of the Risk Management Framework calls for, before any SP 800-53 control is selected. The organization keeps ownership of its risk decisions, roles and boundary. DeployOpen plans, implements and documents the self-hosted open-source platforms inside the client's own environment.

How we scope

The written scope lists which organization-level and system-level Prepare tasks the engagement covers, agreed before work starts.
Scope names the systems in the proposed authorization boundary, along with the design documents and network diagrams we will review.
Engagements are fixed-scope, and a quote follows from the written scope, not from a published price list.

How we build

We deploy self-hosted open-source platforms inside your cloud accounts, data centers or air-gapped networks, so the boundary matches what you can manage.
We prepare the system registration inputs, mission and stakeholder records, and information type inventory that the system owner needs.
We run tests on the platforms we build, covering applications, APIs, cloud and infrastructure, and document the results for the risk assessment.

How we hand over

Deliverables include boundary diagrams, asset inventories and the documented tailoring inputs your organization reviews and approves.
Documents are delivered in the formats agreed in scope, so your assessors and authorizing officials can trace each Prepare output.
Only your organization approves the boundary, baselines and risk decisions, and independent assessors issue any assessment report.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial Prepare work is handed over.
Retainers can keep the continuous monitoring strategy inputs current when systems, boundaries or platform versions change.
Ask us to confirm in writing which parts of the support retainer cover documentation updates and which cover testing and remediation.

The RMF Prepare step: tasks before selecting controls