NIST CSF 2.0 is most useful as an operating cadence, not a binder of security terminology. Used well, it lets an organization compare its current and target security states, assign clear owners, test recovery, and give leadership a measurable, prioritized risk plan—with the framework’s new Govern Function tying those outcomes back to accountability.
Most teams meet NIST CSF 2.0 as a dense PDF of Functions, Categories, and Subcategories, then struggle to turn it into anything they can act on. It is far more useful read the other way around: as a way to make security work visible, assign clear owners, and prove that controls actually operate rather than merely exist. The 2.0 update’s headline change, a new Govern Function, targets the leadership and accountability gaps that tools alone never close.1
This article answers the practical question a mid-market team without a dedicated security department actually faces: once the framework is open on your desk, what do you do with it?
That is where we use the NIST Cybersecurity Framework (CSF) 2.0. The framework gives an organization a taxonomy of cybersecurity outcomes, organized into Functions, Categories, and Subcategories. It is designed to be flexible across organizations, technologies, and sectors; it describes desirable outcomes without prescribing one particular product or implementation method.1
At Datapath, we treat CSF 2.0 as a way to make security work visible and accountable while infrastructure changes. The goal is not to declare that a company is “NIST compliant.” The goal is to know what matters, what is currently true, what must change, and who is responsible for making the change stick.
What is NIST CSF 2.0 actually for?
CSF 2.0 is a common language between executives, IT staff, security practitioners, and an MSP. A finance leader may talk about wire approvals and downtime. An IT manager may talk about identity providers, VLANs, and backup jobs. A security analyst may talk about alert triage and attack paths. CSF 2.0 gives those conversations a shared structure.
The framework has six Functions:
- Govern: establish organizational context, risk strategy, roles, policy, oversight, and supply-chain risk management.
- Identify: understand assets, risks, and opportunities for improvement.
- Protect: control identity, authentication, access, awareness, data security, platform security, and infrastructure resilience.
- Detect: continuously monitor and analyze adverse events.
- Respond: manage, analyze, communicate, and mitigate incidents.
- Recover: execute recovery plans and communicate during recovery.
NIST describes these six Functions as the highest level of organization for cybersecurity outcomes.1 The important operational point is that they are not six isolated departments. A recovery test may expose an identity problem. A network migration may reveal an asset-inventory gap. A phishing exercise may show that incident reporting is unclear.
The newer Govern Function is especially useful for a mid-market company. It forces questions that a tool-centric security review often misses: Which systems are business-critical? What risk can leadership accept? Who can authorize an emergency exception? Which vendors have access to sensitive systems? How often does leadership review unresolved risks?
How should a company use CSF 2.0 during a 90-day transition?
Do not begin by trying to document every Subcategory. Begin with a defined operating scope and a business decision. For the Modesto-to-Manteca consolidation, our scope might be “identity, network access, endpoint security, backup, and incident response for the two offices during the 90-day transition.”
NIST’s Organizational Profile concept supports this approach. A Current Profile describes the outcomes an organization is achieving now, while a Target Profile describes the outcomes it has selected and prioritized for its desired state.1
A practical 90-day sequence looks like this:
Days 1–30: establish the Current Profile
We gather evidence rather than rely on assumptions:
- Export the asset inventory from the existing remote-monitoring and management platform.
- Reconcile users and privileged accounts against Microsoft 365 and the identity provider.
- Review endpoint protection coverage, encryption status, patch age, and local administrator membership.
- Confirm which systems support order processing, production scheduling, accounting, file sharing, and communications.
- Review backup reports and select one representative file share and one critical application for a restore test.
- Document the incident path: who receives an alert, who can isolate a device, who contacts leadership, and who communicates with the business.
This is where “we have backups” becomes a testable statement. The question is not whether a console displays a green checkmark. The question is whether a named person can restore the right data, within an agreed business window, and document the result.
Days 31–60: define the Target Profile
The Target Profile should be written as outcomes and decisions. For example:
| Operating area | Current-state question | 90-day target | Evidence of completion |
|---|---|---|---|
| Identity | Are privileged accounts separated from daily-use accounts? | Administrative access uses named accounts, MFA, and a documented approval path. | Identity report, access review, exception log |
| Endpoints | Are laptops from both offices visible and protected? | 100% of in-scope endpoints report to the chosen management and EDR platforms before cutover. | Device reconciliation and coverage report |
| Network | Can the merged environment be segmented and monitored? | Guest, user, server, and administrative traffic have documented boundaries and alerting. | Network diagram, firewall rules, monitoring test |
| Backup | Has recovery been demonstrated or only scheduled? | Complete one restore test before the migration and repeat it after cutover. | Restore record, elapsed time, data validation |
| Response | Does an employee know where to report a suspicious message? | A one-page escalation path is published, tested, and reviewed with managers. | Tabletop notes, ticket, after-action items |
The numbers in this table are decision criteria for the project, not claims about what NIST requires. CSF 2.0 does not dictate that every organization must reach a particular percentage, deploy a particular EDR product, or complete a restore within a universal time limit. It gives us a structure for selecting and communicating outcomes.
Days 61–90: close gaps and report progress
The Current-versus-Target comparison becomes a prioritized action plan. NIST specifically describes gap analysis and action planning as part of using Organizational Profiles, including options such as a risk register or Plan of Action and Milestones.1
For a company with limited internal capacity, the action plan should distinguish:
- Cutover blockers: missing MFA coverage, unmanaged endpoints, unknown administrator accounts, untested backups, or undocumented firewall changes.
- High-value next actions: vendor-access review, email-authentication improvements, vulnerability remediation, or tabletop incident exercises.
- Planned improvements: security-awareness refreshers, application modernization, broader segmentation, or new reporting metrics.
This is where a Datapath vCIO team can turn a security review into a business-facing roadmap, while our managed cybersecurity services team can provide the recurring monitoring, response coordination, and evidence collection needed to keep the plan current.
Are the six Functions a checklist?
No. A checklist asks whether an activity exists. CSF 2.0 asks whether the organization is achieving an outcome and managing the related risk.
Consider a dispatch environment in a local-government customer. “We have logging” is an activity. A stronger outcome is: relevant events are monitored, suspicious activity is analyzed, the right people are notified, and records support an investigation. For a healthcare clinic, “we run backups” is an activity. A stronger outcome is: critical EHR-dependent workflows can be restored, staff know the downtime process, and the recovery test produces corrective actions.
The same logic applies to a Modesto business consolidating offices. “The firewall is installed” does not answer whether the new network protects administrative traffic, whether remote access is controlled, or whether an outage has a documented fallback.
That distinction prevents a common MSP failure mode: reporting the presence of tools instead of the condition of the business. A named security platform, backup product, or ticketing system is useful only when someone owns the result it is supposed to produce.
What do CSF Profiles and Tiers add?
Profiles answer what state are we in, and what state are we targeting? Tiers add context about the rigor of the organization’s cybersecurity risk governance and management practices.
NIST identifies four Tiers: Partial, Risk Informed, Repeatable, and Adaptive. They range from informal or ad hoc responses toward approaches that are risk-informed, agile, and continuously improving.1 The Tiers can be applied to Profiles, and NIST advises using them to guide and inform risk-management methods rather than treating them as a replacement for those methods.2
For a buyer evaluating an MSP, that distinction matters. A provider should not simply announce, “Your company is Tier 3,” as if it were a pass/fail certification. Leadership should select a realistic level of rigor based on the threat environment, business objectives, regulatory or contractual needs, supply-chain requirements, and available resources.1
A useful management conversation might look like this:
| Question | Weak answer | Accountable answer |
|---|---|---|
| Who owns cyber risk? | “IT handles it.” | A named executive sponsor, IT owner, and security escalation contact are documented. |
| What happens after an alert? | “The SOC investigates.” | The alert path, severity criteria, containment authority, and customer communications are defined. |
| How do we know recovery works? | “Backups completed successfully.” | A restore test has a scope, owner, result, elapsed time, and corrective-action ticket. |
| How do we improve? | “We will review it later.” | Current and Target Profiles are revisited on a defined cadence, with overdue risks reported. |
Can CSF 2.0 replace a compliance program?
No. CSF 2.0 can help organize cybersecurity risk management and map outcomes to other standards, regulations, policies, and contractual requirements, but it does not automatically establish compliance with a specific obligation. NIST describes Informative References as relationships between CSF outcomes and existing standards, guidelines, regulations, policies, or other content.1
That makes the framework useful in regulated Datapath verticals, but not sufficient by itself. A California healthcare clinic may need a separate HIPAA analysis. A county or public-safety organization may need controls and evidence aligned to its applicable CJIS requirements. A bank or credit union may need to address supervisory expectations and its own risk-management program. A school district may have distinct requirements around student information and operational continuity.
In each case, we would scope the obligation first, then use CSF 2.0 to make ownership, gaps, and operating evidence easier to manage. For public safety, our CJIS compliance services can be part of that focused work. For healthcare, our HIPAA-compliant IT services address the environment-specific requirements rather than treating a general framework as a substitute.
What should an MSP deliver from a CSF 2.0 engagement?
A useful engagement should leave the customer with operating artifacts, not just a slide deck. At minimum, ask for:
- A defined scope and list of critical business services.
- A Current Profile with evidence, assumptions, and known gaps.
- A Target Profile tied to business priorities and risk decisions.
- A prioritized action plan with owners, dependencies, and due dates.
- An asset, identity, endpoint, backup, and vendor-access baseline.
- An incident escalation workflow and at least one tabletop or recovery exercise.
- A recurring security report or dashboard that shows completed work, open risks, exceptions, and decisions required from leadership.
The final item is the differentiator. Security is not finished when the framework spreadsheet is completed. It becomes useful when the same team can answer, month after month: What changed? Which risk increased? Which control failed a test? Which decision is waiting for leadership?
How Datapath makes NIST CSF 2.0 operational
We work with organizations in Modesto, Ceres, Manteca, Merced, Fresno, and the wider Central Valley, as well as Irvine and our Ohio markets including Dublin, New Albany, Grove City, Hilliard, and Delaware. For a mid-market company, that local operating context matters: the plan must fit the actual offices, applications, staff, vendors, and business hours—not an imaginary enterprise.
Our role may be fully managed IT, co-managed support for an internal team, vCIO planning, managed cybersecurity, incident-response preparation, or disaster recovery. The technology varies by customer. The accountability does not.
If you are changing offices, replacing an MSP, moving workloads to Azure, or trying to turn a collection of security tools into a defensible operating program, start with one scope and one 90-day Target Profile.3 Then ask whether your provider can produce the evidence, testing, named ownership, and executive reporting to close the gaps.
That is the practical answer to “What is NIST CSF 2.0?” It is a flexible language for cybersecurity outcomes. Used well, it becomes a repeatable management system for deciding what must be protected, proving what is working, and improving what is not. If your current provider cannot show that path, talk with Datapath about building one around your business.
