NIST Cybersecurity Framework as a language between security and management

In February of this year NIST published the first version of the Cybersecurity Framework. The document was prepared following a presidential executive order on protecting critical infrastructure, but it quickly moved beyond that original audience. Companies with no connection to critical infrastructure at all are now reading and applying it.

The reason is straightforward: the framework solves a problem that exists in almost every company - the absence of a shared language between security specialists and management.

What is wrong with the current conversation

The typical information security conversation at the board level takes one of two forms. Either it is a technical monologue after which managers have neither understanding nor the ability to make a decision. Or it is a "everything is fine, we are protected" conversation that says nothing about the actual level of risk.

In both cases management is unable to meaningfully govern this risk - because there is no structure, no metrics, no way to compare "where we are now" with "where we need to be."

NIST CSF tries to solve exactly this.

What NIST CSF is

The framework is built around five functions: Identify, Protect, Detect, Respond, Recover.

Each function is broken down into categories and subcategories. For each there are maturity tiers - from "informal, reactive" to "adaptive, data-driven."

The key point: this is not a technical standard. It is a language for describing the state of security in terms that make sense outside the IT department. "We have good protection but no real process for detecting incidents" is a statement a manager can understand, evaluate, and factor into priorities.

How it works in practice

Applying the framework usually begins with creating a "Current Profile" - an honest description of what is actually done today across each function. Then a "Target Profile" is created - a description of the desired state given the company's risks and resources.

The gap between profiles is the work plan. It can be expressed in priorities, budgets, specific projects. The important thing is that it is tied to business risks rather than technical requirements for their own sake.

This differs from the classic "here is a list of requirements, comply with all of them" approach in that it allows reasoned trade-offs: "here are the three things we do first, because they address the greatest risk given our resources."

What CSF does not solve

The framework is a structure, not ready-made answers. It will not tell you what to do in your specific situation. It creates a frame for diagnosis and conversation.

Also, self-assessment has limitations. A team evaluating its own maturity tends to systematically overrate itself. An external assessment gives different accuracy.

And finally, the framework only works if the security conversation actually happens at the decision-making level. A document filled in to tick a box changes nothing.

A practical question

There is a simple test: if a serious incident occurred in the company tomorrow - a data breach, an infrastructure attack - does management know what to do in the first two hours? Is there a response plan? Who makes the decisions?

If the answer is no, "Respond" in the CSF model is the first section where the conversation should start.