NIST CSF for critical infrastructure operators

How critical infrastructure operators use NIST CSF 2.0 without a certificate

When a board, regulator, sector body or customer asks for NIST CSF alignment, the first thing to establish is that NIST does not certify anyone against the CSF. NIST states that it offers no certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program. That means an operator's controls are judged by whichever assessor, regulator or customer has asked for the evidence, and no body issues a CSF certificate in NIST's name. Cost and timeline depend less on the framework than on scope, the evidence the operator already holds, and the baseline it chooses: CISA's Cross-Sector Cybersecurity Performance Goals 2.0, a sector Community Profile, or the free Cyber Security Evaluation Tool (CSET) maintained with Idaho National Laboratory. Each baseline changes how many outcomes must be evidenced and how much new work follows.

The framework grew out of critical infrastructure. NIST published Version 1.1, titled *Framework for Improving Critical Infrastructure Cybersecurity*, on April 16, 2018, and CSF 2.0 followed as NIST CSWP 29 on February 26, 2024. CSF 2.0 added the Govern Function and widened the intended audience from critical infrastructure to all organizations, regardless of size, sector or maturity. Operators should read that change as a reason to keep their existing critical infrastructure obligations distinct in their documentation, since regulators and sector bodies still set those requirements, not the framework. Before engaging anyone, confirm which regulator or sector body is asking, what it will accept as evidence, and whether it names CSF 2.0, CSF 1.1 or a specific Community Profile.

The division of roles should be settled in writing before work starts. The operator owns its controls, its risk decisions and its accountability to regulators. DeployOpen plans, implements and documents the systems and evidence that show those controls operating, under a fixed scope agreed in advance. Only an independent auditor, assessor or the regulator itself issues any report or finding. A useful first step is to ask the regulator or sector body which baseline it expects, then run CSET or the CPG 2.0 checklist against the current environment to size the gap. The output of that gap check, not a generic estimate, is what should drive a quote.

How CISA's CPGs 2.0 and sector Community Profiles map to the CSF Functions

Operators in critical infrastructure rarely adopt one document. CISA's Cross-Sector Cybersecurity Performance Goals and NIST's sector Community Profiles sit at different levels, so the practical question is which ones to use as a baseline and which to use as a target. The cards below describe each component and the checks to make before you combine them.

CISA cross-sector performance goals 2.0

The CPGs 2.0 are voluntary protections that CISA says critical infrastructure entities of all sizes should implement. They have been updated to follow the six CSF 2.0 Functions. Use them as a short, prioritized starting point for operators that lack a mature program, then map each goal to the Subcategories it supports in your own Current Profile. Confirm the current CPG list on CISA's page before building an internal baseline on it.

The GOVERN function in the CPGs

CPGs 2.0 add a GOVERN function that regroups goals already present in earlier versions and creates new ones. For an operator, this is where leadership accountability, risk strategy and supplier oversight are written down in a form an auditor or regulator can follow. Check whether your existing policies, roles and board reporting already cover the regrouped goals, because gaps here often appear only when the CPGs are mapped to the Functions.

Smaller operators and the CPG focus

CISA states that the CPGs help small and medium-sized organizations start their cybersecurity work by focusing on a limited number of high-impact actions. Operators with limited staff can treat the CPG set as a first-year scope and defer lower-priority CSF Subcategories. Ask your leadership to record which CPG goals were deferred and why, since that decision is the kind of risk acceptance a reviewer will look for.

Sector Community Profiles for transit, telecom and timing

NIST's Profiles page lists Community Profiles for transit, two telecommunications profiles from different publishers, internet routing, foundational positioning, navigation and timing, and semiconductors. Each one is a sector-specific CSF 2.0 baseline. Compare the two telecommunications versions before choosing one, because they may differ in scope and publisher. Confirm each profile's current status on NIST's Profiles page, since drafts and finalized versions can change.

Draft federal Open RAN profile (IR 8623)

The Open RAN profile for federal deployments is listed as a draft under IR 8623. It addresses disaggregated radio access networks, where components from several vendors must be secured together. Operators that build or run such networks should treat it as a reference for supplier requirements and interface risk, not as a finalized target. Recheck the draft status before writing it into contracts or regulatory filings.

Adopting a Community Profile as a Target Profile

A Community Profile becomes useful when your team uses it as a Target Profile and compares it against your Current Profile. Record each Subcategory where your current state falls short, assign an owner and a date, and keep the gap analysis with the Profile itself. Combine the CPGs for the baseline and the sector profile for the target, then document which items you adopted, adapted or excluded. This record is what turns a list of references into evidence of a managed program.

What CISA's free CSET tool does and what it does not replace

The Cyber Security Evaluation Tool (CSET) is a free application that CISA and Idaho National Laboratory develop. It walks an operator through describing its environment, compares that description with security standards and regulations, and recommends improvements. For a critical infrastructure operator, the practical value is structure: CSET turns an informal sense of where the program stands into a documented set of answers that a leadership team can review. Standalone installers require Windows 10 or later, so confirm that the workstations used for the assessment meet that requirement before the team schedules time with them. Check the project's current release notes in the cisagov/cset repository for supported platforms and the standards modules that are available in your version.

CISA said a CSET assessment module for the Cross-Sector Cybersecurity Performance Goals 2.0 was planned for the first quarter of 2026. Treat that as a plan, not a confirmed release date. Before you build a project around it, confirm with CISA or in the repository whether the module is available, which CPG 2.0 items it covers, and how it maps the answers to the CSF 2.0 Functions. If the module is not yet available, a manual worksheet built from the CPG 2.0 goals can serve the same purpose, provided the team records the same evidence for each item.

A CSET result is the operator's self-assessment. It records what the organization believes about its own controls, and it is only as accurate as the people who answered and the evidence they checked. It is not a finding by a regulator, an auditor or CISA, and it does not establish compliance with any rule that applies to your sector. Do not present a CSET report to a board, customer or regulator as an independent assessment. CSET also does not replace a gap analysis against your own Current and Target Profiles, the Tier decisions that go with them, or an independent assessment where your contracts or regulator require one. Use the tool to structure the work, then carry its answers into the risk register and the improvement plan.

Which baseline fits transit, telecom, timing or other operators

Transit operators should first check whether the transit Community Profile on NIST's profiles page applies to their governance or funding conditions. CISA's CPGs 2.0, aligned to the CSF 2.0 Functions, provide a shared set of high-impact actions that can sit underneath the sector view. Start from the profile and the CPGs, then build the Current Profile from what the agency actually runs.

Starting point: the transit Community Profile, read alongside the CPGs 2.0 and their GOVERN function.
First deliverable: a Current Profile covering fare systems, signaling, dispatch, vehicle networks and any vendor-hosted services.
Gap list: the Current Profile compared with the Target Profile, sorted by effect on safety-relevant operations.
Governance: named owners for vendor-operated systems, since many transit networks depend on contractors.
Scope boundaries: a clear line between agency-owned assets and those managed by integrators or transit operators' partners.

Confirm with the transit authority or funder whether the profile is a requirement, a reference or guidance before the scope is written.

How a CSF alignment project moves from baseline to evidence

This sequence turns a vague request to "align with NIST CSF" into a documented baseline, a prioritized action plan and a body of evidence that an independent assessor or regulator can test. The organization owns each decision, and any implementation partner prepares the systems and records behind it.

Confirm the requirement and who asks for it
Start by writing down which party requires CSF alignment, whether that is a regulator, a customer, a contract clause or an internal board decision, and what they will accept as proof. Name the business units, systems and sites in scope and the owner who signs off on the scope. The output is a short scope statement that lists the requester, the expected evidence and the boundary of the assessment. The step is done when the requester has confirmed in writing what they expect to see.
Choose the baseline for the work
Decide which starting point frames the project: the CSF 2.0 Core itself, CISA's Cross-Sector Cybersecurity Performance Goals 2.0, which are aligned to the CSF Functions and suit smaller operators starting out, or a sector Community Profile such as those for transit or telecommunications. Ask the requester whether a specific profile is expected. The output is a recorded baseline decision with the reason for choosing it. The step is done when the owner accepts the baseline and the scope statement references it.
Build the Current Profile
Document how the organization meets each relevant Category and Subcategory today. Engineering, operations and security staff describe what is in place, and the team gathers artifacts such as asset inventories, network diagrams, access reviews, backup records and incident runbooks. Where critical infrastructure includes operational technology, record those systems separately because their owners and constraints often differ. The output is a Current Profile that states the observed status of each outcome, with a link to the supporting record. The step is done when each outcome has a status and an evidence pointer or an explicit note that none exists.
Set the Target Profile and run the gap analysis
Agree the desired outcome for each in-scope Subcategory with the business owners, taking into account the service obligations, risk appetite and any sector requirements. Compare the Target with the Current Profile to list each gap and the size of the change needed. The output is a gap register that lists each shortfall, its affected system or service, and the owner who will close it. The step is done when the leadership group has reviewed the register and accepted the Target as the reference for the next phase.
Prioritize actions by risk and dependency
Rank the gaps by their effect on the critical services, the likelihood of disruption and the dependencies between actions, such as identity controls that other protections rely on. Separate quick, low-cost actions from projects that need capital, vendor work or downtime windows. The output is a prioritized action plan with an accountable owner, a dependency note and a decision on which items are accepted as residual risk and recorded as such. The step is done when leadership approves the plan and the risk acceptances are signed by the people allowed to accept them.
Implement the changes and collect evidence as you go
Carry out the approved actions in the systems and processes in scope, changing configurations, documentation and training as needed. Capture evidence while each change happens, not afterward: change tickets, configuration exports, test results, training attendance and log samples that show the control operating. Where an implementation partner helps, the partner prepares the systems and evidence while the organization keeps ownership of the controls. The output is an evidence library mapped to the Subcategories it supports. The step is done when each closed gap has at least one dated artifact that someone other than the implementer can review.
Hand the evidence to the independent assessor or regulator
Package the scope statement, both profiles, the gap register, the risk acceptances and the evidence library so that an independent assessor or the regulator can trace each claim to its artifact. Confirm with the requester which assessment method and report format they will accept, because NIST does not certify CSF alignment and no conformity assessment program exists for it. The output is an evidence package and an agreed list of open questions. The step is done when the assessor or regulator confirms receipt and the organization knows what, if anything, they will test or issue.

What an operator needs in place before an assessment starts

Before any gap analysis or independent assessment begins, a critical infrastructure operator should be able to show five things: what it runs, who is accountable, who it depends on, how it practices response, and what it is aiming for. Each item below names a CSF outcome, how to check it internally, and what a reviewer will ask to see first.

Current asset inventory

An inventory covering hardware, software, services, supplier-provided services and data is the base for every other CSF outcome (ID.AM). Check that operational technology and field devices appear alongside corporate IT, and that network and data flow maps match the inventory. Reviewers will ask for the inventory export, its last update date, and a sample of assets traced from the map back to an owner. Gaps here usually stall the rest of the assessment.

Named executive owner and policy

Govern expects a named accountable executive and a cybersecurity risk management policy that is reviewed and updated (GV.PO, GV.RR). Check that the policy names the owner, states the review cycle, and was approved by leadership rather than only by the security team. Reviewers will ask for the signed policy, the approval record, and the last review date, and they will ask the owner to explain how the policy shapes funding and priorities.

Risk management strategy on record

The risk management strategy (GV.RM) sets objectives, risk appetite and tolerance, and the standard method used to score risk, all of which should be integrated with enterprise risk management. Check that a risk register exists, that each risk has an owner and a response option, and that the strategy states how positive risks are handled. Reviewers will ask how the register links to the Current Profile and who approved the risk tolerance.

Supplier list tied to obligations

Supply chain risk management (GV.SC) starts with knowing which suppliers and service providers the operator depends on, and which customer or regulator requirements flow down to them. Check that each supplier is linked to the specific obligation it supports, such as a contract clause, a reporting duty, or a sector requirement. Reviewers will ask for the list with criticality ratings, the contract terms covering security, and the offboarding steps for the most critical suppliers.

Incident response exercise records

Improvement (ID.IM) and incident management (RS.MA) are tested through exercises, not only through written plans. Check that the incident response plan exists, that it was exercised recently, and that lessons from each exercise led to tracked changes. Reviewers will ask for the exercise scenario, the attendees, the findings log, and the evidence that corrective actions were closed. A plan with no dated exercise record is hard to credit.

Recorded Target Profile decisions

The Target Profile is the outcome the operator chooses to reach, and it should be a documented decision, not an inherited default. Check that the target was approved by leadership, that each chosen outcome has a stated reason tied to risk or obligation, and that the Current Profile was measured against the same Categories and Subcategories. Reviewers will ask why specific outcomes were set below or above the operator's peers, and who signed off on any gap they accepted.

What CSF alignment costs and who gets paid for each part

This table separates the cost components of aligning a critical infrastructure program to NIST CSF 2.0 and shows who is paid for each, whether the cost is one-time or recurring, and what moves it up or down. DeployOpen does not publish a price list, so a quote follows from the written scope. Use the table to decide which parts to fund internally and which to scope with an outside partner or assessor.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Internal staff time	Your own staff, including OT engineers, operations and leadership	Both: initial mapping is one-time, upkeep is recurring	Number of sites and OT assets in scope, and how many people must review Profiles and evidence
Implementation partner, fixed scope	External partner for systems, controls and evidence preparation	Mostly one-time, with optional retainers for upgrades and testing	Written scope: number of environments, Profile depth, and whether OT networks are included
Tooling (open-source or licensed)	Open-source projects carry no license fee; licensed GRC or monitoring tools are paid to vendors	Licenses and hosting recur; setup is one-time	Choice of self-hosted versus licensed tools, data volume, and whether existing tools already produce evidence
Independent assessor or auditor	Third-party assessor you engage for an independent review	Usually one-time per engagement, repeated on a review cycle	Scope of the assessment, number of Profiles tested, and your evidence readiness
Sector regulator or program fees	Only where a sector body or regulator charges for a program or filing	Confirm with the regulator whether any fee applies	Your sector and jurisdiction; confirm current requirements directly with the regulator

Who owns the controls, who prepares evidence and who issues the judgment

The operator is the critical infrastructure entity that runs the environment and carries the risk. It owns every control in its program, whether the control is run by its staff, a managed service provider or a vendor. Using the CSF does not move that ownership to anyone else, and no implementation partner can accept risk on the operator's behalf.

Decides the Target Profile: The operator selects the outcomes it intends to reach across the Govern, Identify, Protect, Detect, Respond and Recover Functions, based on its mission, dependencies and regulatory obligations.
Accepts residual risk: Leadership decides which gaps are tolerated, funded or deferred, and records that decision in the risk register.
Approves policies: Governing policies under the GV.PO Subcategories must be approved and reviewed by the operator's accountable leaders.
Assigns roles and funding: The operator names owners for each Category and pays for the staff time, tooling and external work that the program needs.

Before engaging a partner, confirm which of these decisions the operator will make internally and which it will delegate in writing.

Questions critical infrastructure operators ask about NIST CSF 2.0

Is there a NIST CSF certification for critical infrastructure operators?

No. NIST does not certify organizations, products or services against the CSF, and it has no plans to create a conformity assessment program. The CSF is voluntary for most organizations, so an operator demonstrates alignment through documented evidence: a current profile, a target profile, a gap analysis and the records that show outcomes are operating. If a customer, regulator or contract asks for proof, ask which document they will accept and whether they want an independent assessment. Only an independent assessor or auditor can issue a report that a third party will rely on. DeployOpen prepares systems and evidence but does not issue reports or certificates. Confirm the exact requirement in writing before you scope any work.

Can we do a CSF alignment ourselves using CSET?

Often yes, for an initial self-assessment, if you have people who understand your environment and the CSF outcomes. CISA and Idaho National Laboratory develop the Cyber Security Evaluation Tool (CSET), a free tool that guides users through describing their environment, compares it with standards and regulations, and recommends improvements. Standalone installers require Windows 10 or later. CSET helps structure the work but does not decide your target profile, set risk tolerance or prove that controls work. Expect the effort to depend on how many systems you run, how well your asset inventory is maintained and how many people must answer for their areas. Independent review becomes more useful when a regulator, customer or board needs a claim that someone else has checked.

How do CISA's CPGs 2.0 relate to the NIST CSF Core?

CISA's Cross-Sector Cybersecurity Performance Goals (CPGs) 2.0 were updated to align with the six CSF 2.0 Functions. They add a GOVERN function that regroups existing goals and creates new ones. The CPGs are voluntary protections that entities of all sizes should implement, and CISA positions them to help small and medium-sized organizations start with a limited set of high-impact actions. Use the CPGs as a prioritized starting list and the CSF Core as the full structure you map your program against. A practical approach is to record which CPG actions you already meet, then find the CSF Subcategories they support and identify the gaps in your Current Profile. CISA says a CSET assessment module for CPG 2.0 was planned for the first quarter of 2026, so confirm its availability before you plan around it.

Do we have to adopt a sector Community Profile?

No. Community Profiles are optional baselines. Adopting one is a choice that makes sense when your sector or technology matches the profile and when a regulator, peer group or customer points to it. NIST's CSF Profiles page lists Community Profiles for transit, telecommunications (two versions from different publishers), internet routing, foundational positioning, navigation and timing, semiconductors and a draft profile for federal Open RAN deployment (IR 8623). Using one as your target can save design work, but you still need to check its assumptions against your own assets, dependencies and risk decisions. Where no profile fits, your organization can build its own Target Profile from the Core. Ask whether any supervisor or contract names a specific profile before you commit, because some profiles are drafts and may change.

How long does CSF work take and what does it need from our staff?

Duration depends on scope, not on a fixed formula. The main drivers are the number of sites and systems in scope, how current your asset inventories and network diagrams are, whether operational technology is included, and how many business owners must confirm answers. Staff time usually goes to the people who own assets, incident response, risk management, supplier relationships and governance. Expect a named internal owner, access to documentation and interviews with operations staff. One-time work includes the baseline profile, gap analysis and first policy set. Recurring work includes evidence collection, periodic reassessment and updating the profile after major changes. Ask any provider for a written timeline tied to a defined scope, the staff roles they expect and the dates on which your input is due.

What should we ask a partner for in a quote?

Ask for a written scope before any price. A useful quote states which sites, systems, networks and OT assets are included, which CSF Functions and Categories are covered, and which deliverables you receive, such as a Current Profile, Target Profile, gap analysis, prioritized roadmap and evidence register. It should name who does each task, what you must provide, what is excluded and how changes to scope are priced. Ask how the partner will work with an independent assessor if you need one, and confirm that the partner will not issue reports or certifications. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, runs security testing and prepares evidence for assessments. Its engagements are typically fixed-scope, and it does not publish a price list, so quotes follow from the written scope. Ongoing support is available as a retainer.

What cost drivers should we expect for CSF work?

Costs fall into a few groups: internal staff time, external consultant or partner fees, assessor fees if you commission an independent review, and any tooling or hosting you add. One-time costs include the initial assessment, profile design and remediation projects. Recurring costs include evidence collection, reassessments, monitoring and staff training. Costs rise with the number of sites, the amount of legacy or OT equipment, the quality of existing documentation and the number of regulatory obligations that must map to the same evidence. Costs fall when inventories are accurate and the scope is limited to what regulators or customers actually require. Because NIST publishes no price guidance for CSF work, request line-item quotes from each provider and compare what each one covers rather than totals alone.

How DeployOpen scopes and prepares CSF evidence for operators

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the operator's own infrastructure, whether that is the operator's cloud accounts, data centers or air-gapped networks. For a critical infrastructure operator, that work usually starts with the systems that carry operational and business data, such as the asset inventory, identity and access services, log collection, backup and the monitoring stack. DeployOpen prepares these systems and the controls around them so the operator's own staff can show how each CSF 2.0 Subcategory is met, including where the evidence lives and who owns it. The operator still owns its controls, its risk decisions and its Organizational Profiles. DeployOpen's role is to build and document the environment those decisions depend on.

Most engagements are fixed-scope. Before work begins, the parties agree in writing which systems, controls and CSF Functions are in scope, what deliverables will be handed over and on what timeline. A quote follows from that written scope, so the operator can see which costs come from the number of systems, the depth of hardening and the volume of evidence to be produced. Ask for the scope to name the sector profile or CISA CPG items being targeted, the owner of each deliverable and the acceptance criteria. Ongoing support, upgrades and continuous testing are available as retainers for operators that need to keep evidence current after the first delivery, since monitoring and backup records lose value quickly if nobody maintains them.

DeployOpen does not issue audit reports, attestations or certifications, and it does not guarantee a result. NIST does not certify CSF implementations either, so any assessment an operator relies on, whether internal, by a sector regulator or by an independent assessor, is performed by that party. DeployOpen's work is judged by whether the evidence it helps produce is accurate, complete and retained. Before engaging, confirm with your regulator or the entity requesting the assessment which evidence and assessor types it accepts, and make that requirement part of the written scope.