Before You Protect Anything, Decide Who Is Accountable

GOVERN: Cybersecurity Governance in Plain English

A Special Six-Part Series for The Cyber Governance BriefSubscribers

Before we begin, a word about why you are receiving this series.

Over the next two weeks, I am publishing six articles created specifically for subscribers to The Cyber Governance Brief. They will not be distributed as regular LinkedIn posts.

I wanted to do something different for the readers who have chosen to subscribe and follow this work more closely.

So we are going to take one of the most important developments in modern cybersecurity governance—the GOVERN Function in the NIST Cybersecurity Framework 2.0—and strip away the standards language.

No framework expertise required.

No cybersecurity certification required.

Just six conversations about decisions every organization eventually has to make.

And we begin with the most important one.

Who is accountable?

Imagine This Happens Tomorrow

Your organization discovers ransomware spreading through its environment.

Someone needs to decide whether to shut down a critical business system.

Who has that authority?

The Chief Information Security Officer?

The CIO?

The CEO?

The business executive responsible for the affected operation?

Now consider something less dramatic.

A critical supplier cannot meet one of your cybersecurity requirements, but replacing that supplier would disrupt the business.

Who can accept the risk?

Or marketing wants to deploy a new technology platform that could materially increase revenue, but the security team believes the platform introduces unacceptable risk.

Who gets the final word?

Or your security team discovers a serious vulnerability in a production system. Fixing it immediately would require taking the system offline during your busiest period.

Who decides whether to patch now or wait?

These may sound like cybersecurity questions.

They aren’t.

They are governance questions.

And if the answers are being invented while the incident is happening, the organization has already discovered a governance problem.

Cybersecurity Used to Have Five Familiar Words

For years, many executives encountered the NIST Cybersecurity Framework through five Functions:

IDENTIFY. PROTECT. DETECT. RESPOND. RECOVER.

They provided a remarkably understandable way to think about cybersecurity.

Understand what you have and the risks surrounding it.

Protect what matters.

Detect when something goes wrong.

Respond to the incident.

Recover what was affected.

Then NIST released Cybersecurity Framework 2.0 in February 2024 and made a significant change.

It added a sixth Function:

GOVERN.

This wasn’t simply another word added to the list. NIST explicitly increased the framework’s emphasis on governance and designed CSF 2.0 for organizations of all sizes and sectors, not merely critical infrastructure. (NIST)

That change deserves more attention than it sometimes receives.

Because GOVERN changes the conversation.

GOVERN Is Not Another Security Control

This is where the terminology can become misleading.

When people hear “cybersecurity governance,” they may imagine policies, committees, compliance meetings, documentation, or another administrative layer sitting above the security program.

Those things may be involved.

But they are not the essence of governance.

In plain English, GOVERN asks:

How will we make cybersecurity risk decisions, and who is accountable for making them?

NIST defines GOVERN around establishing, communicating, and monitoring an organization’s cybersecurity risk-management strategy, expectations, and policy. More importantly, NIST says GOVERN informs how the other five Functions should be achieved and prioritized within the context of the organization’s mission and stakeholder expectations. (NIST Publications)

That distinction matters.

GOVERN isn’t simply something you do before moving on to IDENTIFY.

It surrounds the entire cybersecurity risk-management system.

NIST’s own CSF 2.0 graphic reinforces this architecture: GOVERN forms an inner ring connecting the framework’s other Functions. NIST also makes clear that the Functions are not sequential steps; GOVERN, IDENTIFY, PROTECT, and DETECT should occur continuously, while RESPOND and RECOVER must remain ready when incidents occur. (NIST)

Think of it this way:

GOVERN — Decide how cybersecurity risk will be managed and who is accountable.

IDENTIFY — Understand what you have and what could go wrong.

PROTECT — Put safeguards in place.

DETECT — Recognize possible attacks and compromises.

RESPOND — Take action when an incident occurs.

RECOVER — Restore affected assets and operations.

The other five Functions describe essential cybersecurity outcomes.

GOVERN establishes the decision environment in which those outcomes are pursued.

Someone Still Has to Decide

Suppose your CISO tells the executive team:

“We have a critical vulnerability.”

That is information.

The security team then says:

“We recommend taking the affected system offline immediately.”

That is a recommendation.

Operations responds:

“If we take that system down today, we cannot ship customer orders.”

That is business impact.

Finance adds:

“Every hour of downtime costs us $250,000.”

That is financial exposure.

Legal identifies a contractual obligation that could be affected.

Now what?

There may be no technical answer to the question.

The vulnerability is real.

The operational impact is real.

The financial exposure is real.

The contractual obligation is real.

Someone must decide.

And that decision implicitly answers several governance questions:

Who has authority?

What level of cyber risk is acceptable?

What level of business disruption is acceptable?

Which organizational objectives take priority?

Does the decision require escalation?

Who must be informed?

Who documents the exception?

When will the decision be reconsidered?

Who ultimately owns the resulting risk?

That is GOVERN in action.

The Six Questions Behind GOVERN

NIST divides GOVERN into six Categories. The official terminology is useful, but the underlying questions are much easier to understand.

Organizational Context (GV.OC)

What does our organization do, what matters to it, whom do we serve, what do others expect from us, what do we depend upon, and what legal, regulatory, and contractual obligations affect our cybersecurity decisions?

Risk Management Strategy (GV.RM)

How much cybersecurity risk are we prepared to accept, and how will we evaluate, prioritize, communicate, and respond to that risk?

Roles, Responsibilities, and Authorities (GV.RR)

Who owns what? Who has authority to make decisions? Who performs the work? Who gets informed? And who answers for the outcome?

Policy (GV.PO)

What cybersecurity expectations has the organization established, and how are those expectations communicated, maintained, and applied?

Oversight (GV.OV)

How does leadership determine whether the cybersecurity risk-management strategy is actually producing the intended results?

Cybersecurity Supply Chain Risk Management (GV.SC)

How do we govern cybersecurity risk created by suppliers, service providers, partners, and other third parties upon whom the organization depends?

These are the six areas we will explore throughout this series. They are the Categories NIST places beneath the GOVERN Function in CSF 2.0. (NIST)

Notice how few of those questions are fundamentally about technology.

They are about the organization.

This Is Why Cybersecurity Cannot Belong to IT Alone

Technology teams have enormous responsibilities within cybersecurity.

Security professionals understand threats, vulnerabilities, controls, architecture, detection, response, and technical exposure in ways most executives understandably do not.

But technical expertise does not automatically confer business authority.

A CISO can explain why a vulnerability is dangerous.

The CISO may not have authority to accept the financial consequences of shutting down a manufacturing plant.

A security architect can explain why a vendor creates risk.

The architect may not have authority to terminate a strategic supplier relationship.

A SOC can identify an attack.

The SOC does not necessarily have authority to make every consequential business decision that follows.

This is where organizations sometimes confuse managing cybersecurity with governing cybersecurity.

Management operates the system.

Governance establishes the boundaries within which consequential decisions are made, determines who possesses decision rights, and provides oversight of the results.

NIST’s decision to elevate GOVERN reflects that broader reality. The framework specifically connects cybersecurity governance with enterprise risk management rather than treating cyber risk as an isolated technical discipline. (NIST Publications)

The Board Has a Role, But GOVERN Does Not Mean “The Board Does Cybersecurity”

This distinction is equally important.

Moving cybersecurity into governance does not mean boards should select firewalls, evaluate endpoint products, approve individual vulnerabilities, or choose security architectures.

That would collapse governance into management.

The board’s responsibility is oversight.

Management’s responsibility is execution.

The governance system should establish which decisions belong where, how material risks are escalated, what information leadership receives, and how accountability is maintained.

A healthy governance structure prevents two opposite failures.

In one, the board knows too little and cannot exercise meaningful oversight.

In the other, the board reaches too deeply into operational decisions and begins functioning as management.

Neither is good governance.

The Question Isn’t “Are We Secure?”

There is another reason GOVERN matters.

Organizations frequently ask a question cybersecurity cannot really answer:

Are we secure?

Secure against what?

At what cost?

For which systems?

Against which threat actors?

With what tolerance for operational disruption?

For how long?

Cybersecurity does not produce a permanent state called “secure.”

Organizations operate with risk.

They reduce some risks.

Accept others.

Transfer some through contracts or insurance.

Avoid certain activities altogether.

And sometimes they knowingly operate with significant exposure because another business objective takes priority.

Those decisions are unavoidable.

The governance question is whether they are made deliberately, by people with the proper authority, using appropriate information—and whether the organization can later demonstrate why the decision was reasonable.

That is a much more mature question than:

“Are we secure?”

Before You Protect Anything

There is a reason I chose accountability as the starting point for this series.

You can buy excellent cybersecurity technology.

You can hire talented security professionals.

You can implement sophisticated controls.

You can monitor thousands of security events.

You can develop incident-response plans and conduct tabletop exercises.

You can maintain backups and recovery environments.

And still have weak cybersecurity governance.

Because eventually something will happen that requires a decision no tool can make for you.

A risk will need to be accepted.

An exception will need to be approved.

A system may need to be shut down.

A supplier may need to be challenged.

A business initiative may need to be delayed.

An incident may need to be disclosed.

A regulator may ask who knew what and when.

A board may ask why a particular risk was never escalated.

At that moment, cybersecurity becomes a question of authority and accountability.

And that is why NIST put GOVERN where it did.

Cybersecurity governance begins when an organization stops asking only:

“Are we secure?”

and starts asking:

“Who is accountable for deciding what secure enough means?”

That is GOVERN.

And in the next installment, we’ll start with the first thing an organization must understand before it can govern cybersecurity risk:

the business itself.