NIST CSF for federal agencies and FISMA

Do federal agencies have to use NIST CSF 2.0 alongside FISMA?

Yes, U.S. federal agencies are required to use the CSF. The 2017 executive order on strengthening federal networks and critical infrastructure made the framework mandatory for federal agencies, and it sits alongside FISMA and the Risk Management Framework rather than replacing them. The CSF gives an agency a shared language for outcomes across Govern, Identify, Protect, Detect, Respond and Recover, while FISMA, OMB policy and the RMF still decide how a system is categorized, how controls are selected, and who authorizes it to operate. If you run an agency program or support one as a contractor, treat the CSF as the outcome view that your SP 800-53 control set has to be explained against.

The executive order directed each agency head to send a risk management report, including a plan to implement the framework, within 90 days. Confirm with your agency's cybersecurity office where that report stands today and whether the plan has been updated since CSF 2.0 was published as NIST CSWP 29 on February 26, 2024. Who owns what matters here. The agency owns its controls, decides which ones apply to each system, and accepts the residual risk. An implementation partner can prepare system documentation, control evidence and gap analysis material, but it does not make the determinations. Independent assessors test the controls, and the agency's authorizing official decides whether a system may operate. Ask any partner to state that division of roles in writing before work begins.

For a contractor, the practical question is what the agency will ask to see in your environment and in what form. Confirm the specific SP 800-53 baseline, the FISMA reporting obligations and any CSF alignment expectations written into the contract, then map your evidence to the framework's outcomes so the same artifacts answer both the CSF view and the RMF assessment. Do not assume that a CSF profile alone satisfies an authorization package. The CSF tells you what outcomes to show, and the RMF and SP 800-53A procedures tell the assessor how to test them.

How the CSF, the RMF and SP 800-53 fit together

The CSF 2.0 Core is a set of cybersecurity outcomes organized into six Functions (Govern, Identify, Protect, Detect, Respond and Recover), 22 Categories and 106 Subcategories. It describes what an organization should achieve but does not prescribe how to build each safeguard. For a federal agency, the Core gives leaders a common vocabulary for priorities, gap analysis and reporting to executives and boards. The 2017 executive order required agency heads to send risk management reports that included a plan to implement the framework, so the Core is the layer where that plan is written.

Outcome language: Subcategories state results, such as an inventory being maintained, not the technical method for achieving it.
Organizational Profiles: Current and Target Profiles show where the agency stands and where it intends to be.
Tiers: Partial, Risk Informed, Repeatable and Adaptive describe how formal and consistent the risk practices are.
Executive reporting: Govern Subcategories give leaders a structure for oversight and risk strategy.
Mapping: Informative references connect each outcome to SP 800-53 Rev. 5.2.0 and other standards.

Check whether your agency's CSF plan maps each Target Profile outcome to a named owner and to the RMF artifacts that will demonstrate it.

How the SP 800-53 crosswalk supports agency reporting

The NIST CSF 2.0 Reference Tool export links each Subcategory to the informative references that help an agency show how its controls support its outcomes. The cards below cover what the crosswalk contains, how to use it in FISMA reporting, and where agency teams still need to check the mappings themselves.

Full SP 800-53 coverage of the Core

The Reference Tool export maps SP 800-53 Rev. 5.2.0 to every one of the 106 CSF 2.0 Subcategories, using 213 distinct controls and enhancements. An agency can start from that complete set instead of building its own mapping from scratch. Confirm the revision your authorization packages use, because a mapping to one SP 800-53 revision does not automatically carry over to another.

Using NICE references for workforce outcomes

The NICE Framework references also cover all 106 Subcategories, so the same export can connect workforce roles and skills to the outcomes they support. This helps agency officials show which teams perform which activities when they report on governance and training. Check that the role names in the export match the titles in your own position descriptions before citing them in reports.

Showing which controls evidence outcomes

Use the crosswalk to trace each CSF Subcategory to the SP 800-53 controls that produce evidence for it, such as access control records, configuration baselines or incident logs. Reviewers then see a path from a leadership-level outcome to a control and its artifact. Record the chain in your system security plan so that the same evidence is not claimed against several outcomes without explanation.

Verifying mappings against system boundaries

A crosswalk describes the framework in general, while an authorization covers a defined system boundary. A control that is inherited from an enterprise service may not be implemented by a given system, and a control that is partly implemented may not satisfy an outcome on its own. Test each mapped control against the boundary, the inheritance decisions and the assessment results recorded for that system.

Rechecking references after NIST updates

NIST publishes Informative References, Implementation Examples and Quick-Start Guides online, separately from the framework document, so these can change more often than CSWP 29. Assign an owner to check the NIST updates archive and the Reference Tool at a set interval and whenever SP 800-53 is revised. Record the export date and version in your reporting package so that a reviewer can see which mapping supported a given report.

Turning mappings into board-ready reports

Agency leaders need a short view of outcome status, not a full control catalog. Summarize each CSF Function with the mapped controls, the evidence owners and any open gaps, then link the detail to the authorization record. Ask your reporting team to confirm the report format required by your agency and the reporting cycle set by your Chief Information Officer before building the summary.

Using NIST ERM guidance to report risk to agency leaders

NIST SP 1303 is the piece of NIST guidance that connects the CSF to enterprise risk management, and it matters most for agency officials who have to explain cybersecurity progress to leaders who oversee all relevant risks. SP 1303 describes the CSF process as a way to help ensure cybersecurity strategy is well executed, with managers recording progress and reporting it upward. For an agency, the practical decision is who owns that record: the program office that runs the CSF Profiles, or the enterprise risk function that reports to the agency head. Confirm that answer before the first report goes out, and make sure the Current and Target Profiles feed a risk register that leaders already review, so that CSF gaps show up in the same terms as other agency risks.

CSWP 29 lists several NIST resources for this work. *IR 8286* and its parts, IR 8286A through 8286D, cover identifying, prioritizing and staging cybersecurity risks, and they address business impact analysis. Staff who build the risk inputs for a federal agency will use these documents to decide which risks rank first and how a risk is tied to a business function, which is the question an agency head asks before funding a remediation. *SP 800-221* and *SP 800-221A* address ICT risk within the enterprise risk portfolio, so they help the agency place technology risks alongside its other enterprise risks rather than treating them as a separate IT issue. Pull the current revisions from the NIST publication pages before adopting either set, since CSWP 29 is a reference list and does not describe how an agency should apply each document.

The ERM Quick-Start Guide is the entry point for this work, and CSWP 29 names it among the resources. A useful test for the agency is whether a leader can trace one reported cybersecurity gap to a named risk owner, a risk response decision and a date for review. Illustrative example: an agency reports that a Target Profile outcome for asset inventory is not yet met. The report should state the affected business function, the risk owner, the response chosen (accept, mitigate, transfer or avoid), and the review date. Ask your agency risk office whether it already uses this structure, because reusing its risk template usually makes the CSF reporting easier to accept at leadership level. Also check which NIST documents the agency's own policy names as authoritative, so the ERM work and the RMF work do not give leaders two different risk numbers.

How an agency moves from CSF plan to assessed FISMA program

The sequence turns an agency's CSF implementation plan into profiles, control mappings, remediation through the Risk Management Framework, assessment evidence and reporting that leaders and the agency's authorizing chain can review. Each step ends with a named output so progress can be checked against the plan.

Confirm scope and system boundaries
The agency head or chief information officer, with the authorizing officials, decides which mission areas, organizational units and information systems the CSF effort covers. Security and privacy staff document the system boundaries that already exist for FISMA authorization, including systems operated by contractors on the agency's behalf, so the profile and the control mapping describe the same systems. The output is a signed scope statement with a system inventory cross-referenced to authorization boundaries. The step is complete when every in-scope system has one owner and one boundary record.
Build current and target organizational profiles
Cybersecurity leads, with business and mission owners, use the process in NIST SP 1301 to record the current state of each CSF Subcategory and to set a target state that reflects mission priorities and risk tolerance. The Govern Function should be addressed first so that target outcomes reflect agency risk appetite and leadership direction. The outputs are a Current Profile and a Target Profile, each with a short justification for every Subcategory where the agency is not yet at its target. The step is complete when leaders have reviewed and approved both profiles.
Map Subcategories to SP 800-53 controls
Security engineers and compliance staff use the informative references in the CSF 2.0 Reference Tool to connect each Subcategory to the SP 800-53 Rev. 5 controls that the agency already selects and tailors under its baselines. This shows which Subcategories are already supported by implemented controls and which rely on controls the agency has not yet selected or implemented. The output is a crosswalk workbook linking each Subcategory to control identifiers, with a column for the owning system. The step is complete when every gap between the two profiles has at least one candidate control or a documented reason none applies.
Close gaps through the Risk Management Framework
System owners and authorizing officials carry the gaps into the RMF lifecycle described in SP 800-37 Rev. 2, where selected controls are implemented, documented in system security plans and risk-assessed using SP 800-30 methods. Gaps that cannot be closed in the near term are recorded as risks with an accepted or planned response. The output is updated security plans, plans of action and milestones, and risk decisions for each affected system. The step is complete when each gap has an owner, a documented response and a recorded authorization decision or risk acceptance.
Gather assessment evidence for each control
Independent or organizationally separate assessors follow the procedures in SP 800-53A Rev. 5 to test whether each selected control is implemented correctly and operating as intended. Assessment evidence, such as configuration baselines, scan results, access reviews, log samples and test records, is linked back to the Subcategories it supports. The output is an assessment package per system, with findings and evidence references. The step is complete when each in-scope system has a documented assessment result and each finding has a remediation record or accepted risk.
Measure progress against the target profile
Cybersecurity program managers compare assessment results with the Target Profile to determine which Subcategories have moved from Current to Target and which remain open. Progress is recorded as metrics that show trends for leadership, not as a single compliance score. The output is a periodic progress report that identifies changed Subcategories, open gaps and the evidence behind each change. The step is complete when the report has been reconciled with the risk register and the plan of action and milestones.
Report through the agency's chain of command
The chief information security officer or equivalent prepares the report, which goes to senior agency leaders and then through the agency's internal governance to the agency head. The report follows the agency's enterprise risk management process, as described in NIST SP 1303, so that cybersecurity risks are weighed alongside other enterprise risks. Agencies should confirm the reporting format and submission channels required by their oversight bodies, since these are set by the agency and federal guidance rather than by the CSF itself. The output is a leadership briefing and the risk management report required under the 2017 executive order. The step is complete when leaders have acknowledged the report and the decisions taken are recorded.

What agencies and contractors need in place before assessment

An independent assessor testing a CSF-aligned FISMA program will ask for the same core artifacts every time: what systems exist, where their boundaries sit, what risks are open, what the target is, how each control is met and where the proof lives. The cards below cover the six items the organization must check before the assessor arrives, since gaps in any one of them tend to surface as findings.

Current asset and system inventories

The inventory is the starting point for every other artifact. It should list hardware, software, services, and the information systems that process agency or contractor data, with an owner and a status for each. Before the assessor arrives, check that the inventory matches what discovery tools and cloud accounts actually show, and that systems operated by contractors on the agency's behalf appear in it. An inventory that omits a system invalidates the controls mapped to it.

Documented system boundaries

A boundary defines which components, data flows and users fall inside the system being authorized. Agencies and contractors should be able to show a current diagram, the external connections that cross the boundary, and the reason each connection is in scope. Check that the boundary in the system security plan matches the network and cloud diagrams. Mismatches between the drawn boundary and the real one are a common reason an assessor cannot rely on the controls claimed.

Current risk register

The risk register records the threats, vulnerabilities and business impacts the organization has identified, along with the response chosen for each and the owner accountable for it. It should connect to the risk assessment performed under SP 800-30 and to the risk decisions recorded in the RMF authorization package. Before assessment, confirm that entries have dates, that accepted risks have an approving official, and that the register reflects the most recent scan and incident results rather than a snapshot from an earlier cycle.

Approved Target Profile

The Target Profile states the cybersecurity outcomes the agency or contractor intends to reach, expressed against the CSF 2.0 Subcategories. It should carry a documented approval from the accountable leader and a date. Check that the Target Profile is consistent with the Current Profile used in the gap analysis, and that the outcomes it sets can be traced to the SP 800-53 controls selected for the system. An assessor will compare the claimed target with the evidence, so an unapproved or outdated target undermines the rest of the package.

Control implementation statements

Each selected control needs a statement that names the responsible party, describes how the control is implemented in this system and states whether it is inherited, shared or system-specific. These statements are what the assessor reads first. Before assessment, check that every control in the baseline has a statement, that inherited controls cite the provider's documentation, and that the wording matches what the configuration actually does. Statements that describe an intended design rather than the deployed state are a frequent source of findings.

Evidence repositories

An evidence repository holds the artifacts that prove each implementation statement: configuration exports, scan reports, access review records, backup test results and incident tickets. Organize it by control identifier so an assessor can move from a statement to its proof without help. Before assessment, check that evidence is dated, that its source system is named, that access to the repository is restricted, and that older artifacts are retained according to the agency's record schedule. Self-hosted tooling can generate much of this evidence, but the organization must confirm that the tool's logs are complete and tamper resistant.

Who owns the controls, who prepares evidence, and who authorizes

The agency owns its controls, its risk decisions and its authorization decisions. Under the Risk Management Framework described in SP 800-37 Rev. 2, the authorizing official decides whether the risk of operating a system is acceptable, and that decision cannot be delegated to a vendor or consultant. The agency also decides how the CSF Organizational Profiles are set, what the Target Profile says, and which Tier it expects to reach. Those choices appear in the agency's risk management report, which the 2017 executive order required each agency head to send within 90 days, including a plan to implement the framework.

Control ownership: Each control has a named owner who is accountable for its design and operation, not only for producing documents.
Risk acceptance: The authorizing official signs the decision to accept residual risk, based on the assessment results and the system security plan.
Profiles and Tiers: Leadership approves the Current and Target Profiles and the Tier the agency is aiming for.
Reporting: Agency managers record progress and report it upward, as SP 1303 describes for enterprise risk management.
Contractor oversight: Where contractors operate systems for the agency, the agency still owns the authorization and must confirm that contractor evidence meets its requirements.

Before engaging any outside party, confirm internally who holds each role and write those assignments down.

Questions federal and contractor teams ask about CSF and FISMA

Does NIST CSF 2.0 replace SP 800-53 controls for federal systems?

No. The CSF complements SP 800-53 rather than replacing it. CSWP 29 says the CSF can be integrated with the Risk Management Framework (SP 800-37) and SP 800-30 risk assessments, and that it can complement the RMF's approach to selecting and prioritizing SP 800-53 controls. SP 800-53 Rev. 5 controls are mandatory for federal information systems under OMB Circular A-130 and FISMA. The CSF gives leaders an outcome-based view of the program, while SP 800-53 supplies the control catalog that assessors test. NIST's CSF 2.0 Reference Tool export maps SP 800-53 Rev. 5.2.0 references to all 106 Subcategories, which is a useful starting point for agency teams, but the mapping should be reviewed against the agency's own system boundaries and authorization decisions.

Must federal contractors adopt NIST CSF 2.0?

The supplied facts say the 2017 executive order made the CSF mandatory for U.S. federal agencies, and it directed agency heads to send risk management reports including implementation plans. The order itself does not set obligations for contractors. Whether a contractor must align to the CSF depends on the terms of each contract, task order or agency requirement, which may cite the CSF directly or cite SP 800-171, SP 800-53 or FISMA controls for systems that handle federal information. Contractors should read the statement of work, security clauses and any agency-specific requirements, then confirm with the contracting officer which framework evidence is expected. Ask whether the requirement applies to the contractor's own systems, to systems operated for the agency, or to both.

How long does it take to align an agency or contractor program to CSF 2.0?

No researched timeline is available for this, so treat any duration you hear as unverified. The time depends on the size of the environment, how current the asset inventory and policies are, whether a Current Profile already exists, and how many systems fall under FISMA authorization. Ask your assessor or implementation partner to scope it in phases: a Current Profile of the Govern and Identify outcomes, a gap analysis against a Target Profile, then prioritized remediation. Request a written scope that lists the systems, Functions and evidence deliverables covered, and the dates each phase depends on, including agency review cycles and authorization timelines.

What effort must the agency provide to support a CSF engagement?

The agency owns its controls, so its staff must supply most of the inputs that an outside team cannot create alone. Typical contributions include access to system owners, current asset and data flow inventories, existing policies, risk assessments, authorization packages, incident response plans and records of past tests. Staff must also review draft profiles, decide on risk acceptance and approve the target state. Ask for a named owner on each side, a list of documents needed in week one, and a schedule of interviews and reviews. Effort from the agency usually rises when system documentation is scattered or when several components share authorization boundaries.

Can an implementation partner prepare CSF and FISMA evidence for us?

Yes, within a defined scope. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and NIST does not offer CSF certification or endorse implementation services. For federal work, the agency's authorizing official, its assessors and its independent assessment team make the formal determinations. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so ask for the list of Subcategories, systems and evidence artifacts that will be produced.

Who signs off on CSF alignment and FISMA authorization decisions?

The organization's leaders own the decision to accept risk and to report alignment, and in federal systems the authorizing official makes the authorization decision under the Risk Management Framework. Independent assessors test the controls and report findings, and implementation partners prepare systems and evidence but do not sign off on compliance. For the CSF itself, NIST does not run a conformity assessment, so any claim of alignment is an internal statement unless an independent assessor reviews it. Agree in advance who approves the Target Profile, who accepts residual risk, and which reports go to agency leadership, following the governance practices described in SP 1303.

Can a team run this alignment without outside help?

Many agencies and contractors have the internal skills to do part of the work, especially the Govern and Identify outcomes, where the organization's own context, policies and risk decisions matter most. The harder parts are usually the gap analysis across many systems, the mapping to SP 800-53 control evidence, and the independent-looking documentation that assessors expect. Decide which pieces your staff will own, which will be supported by an outside team, and which will be tested by an independent assessor. Ask whether internal staff have time for the project alongside authorization and operational work, since resource constraints are often the factor that changes the schedule.

How DeployOpen prepares agency systems and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the agency's own infrastructure, so the systems and records that support its NIST CSF 2.0 and FISMA work are built to be inspected. We prepare controls and evidence; the agency owns its risk decisions, and independent assessors issue any findings or authorization outcomes.

How we scope

Engagements are fixed-scope, with systems, CSF Subcategories and deliverables agreed in writing before work starts.
We confirm which information systems, boundaries and SP 800-53 control selections the agency's authorization package already covers.
Scope documents name who owns each control, which parts DeployOpen prepares, and which parts the agency or its assessor will verify.

How we build

We deploy and harden open-source platforms in the agency's cloud accounts, data centers or air-gapped networks.
Configurations map to CSF Subcategories and to the SP 800-53 controls the agency selected, so each setting has a traceable purpose.
We configure logging, access control and backups to produce the records an assessor would ask to sample.

How we hand over

Deliverables include system documentation, control mapping workbooks, configuration baselines and procedures written for agency staff.
Evidence packages are organized by control so assessors can trace each claim to a configuration, log or test result.
Security testing results are delivered with remediation tracking, and the agency decides which risks to accept.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial scope closes.
Retainers can cover evidence refreshes ahead of annual reviews and changes to platform versions or authorization boundaries.
Ask any partner to confirm in writing which parts of the FISMA process remain with agency officials and the independent assessor.

NIST CSF for federal agencies and FISMA programs