You Cannot Govern Cyber Risk Without Understanding the Business

GOVERN: Cybersecurity Governance in Plain English

Part 2 of the TCGB Subscriber Series

In the first article of this series, we started with accountability.

• Who decides?
• Who has authority?
• Who accepts risk?
• Who answers for the outcome?

But there is a question that has to come immediately afterward:

Accountable for what?

You cannot answer that question by looking at a firewall.

You cannot answer it by counting vulnerabilities.

And you certainly cannot answer it by opening a cybersecurity dashboard and looking for the largest red number.

You have to understand the business.

That is why the first Category beneath GOVERN in the NIST Cybersecurity Framework 2.0 is called Organizational Context, or GV.OC.

The name sounds formal.

The idea isn’t.

Before an organization can intelligently govern cybersecurity risk, it needs to understand what it does, what matters, who depends on it, what it depends on, and what obligations it has made to others.

Without that context, cybersecurity risk is just a collection of technical problems competing for attention.

Not Everything Is Equally Important

Imagine two servers.

Both have the same critical vulnerability.

One hosts an internal application used by twelve employees to submit expense reports.

The other supports the system used to process every customer order.

Technically, the vulnerability may be identical.

From the perspective of the business, the risks are not.

If the expense application becomes unavailable for four hours, employees may be inconvenienced.

If the order-processing system becomes unavailable for four hours, revenue stops.

• Customers are affected.
• Contractual commitments may be missed.
• Operations may back up.
• Call volumes may increase.
• Reputation may suffer.

The cybersecurity issue has not changed.

The business context has.

And context changes risk.

Start With the Mission

NIST begins Organizational Context with a deceptively simple outcome:

The organization’s mission should be understood and should inform cybersecurity risk management.

That sounds obvious.

In practice, it can fundamentally change how cybersecurity priorities are established.

Consider a hospital.

Its mission is not to maintain servers.

It is not to operate a security operations center.

It is not to achieve a particular vulnerability score.

It exists to deliver healthcare.

Now imagine ransomware affects several systems simultaneously.

One supports administrative reporting.

Another supports patient registration.

Another provides access to clinical information used in patient care.

Which system receives priority?

A purely technical assessment might examine severity, exploitability, network exposure, or the number of affected assets.

Those factors matter.

But organizational context introduces another question:

Which system matters most to the mission?

Suddenly cybersecurity prioritization becomes much clearer.

Protecting the mission is the objective.

Cybersecurity is one of the mechanisms used to accomplish it.

Who Depends on You?

Organizations rarely exist only for themselves.

Customers depend on them.

Patients depend on them.

Citizens depend on them.

Employees depend on them.

Business partners depend on them.

Investors depend on them.

In some industries, entire communities may depend on them.

NIST therefore asks organizations to understand both internal and external stakeholders and their cybersecurity-related needs and expectations.

That can sound abstract until something goes wrong.

A customer may expect you to protect confidential information.

A business partner may expect your systems to remain available so that its own operations can continue.

A regulator may expect specific safeguards or reporting.

A board may expect material cyber risks to be escalated.

Employees may expect payroll and benefits systems to function.

Investors may expect cyber risk to be managed as part of enterprise risk.

These expectations do not all carry the same weight.

Some are informal.

Some are contractual.

Some are regulatory.

Some may create significant financial or reputational consequences.

But collectively, they help define what cybersecurity must accomplish.

What Have You Promised?

This is one of the areas where cybersecurity governance quickly becomes larger than the security department.

Organizations accumulate obligations.

Some come from laws.

Some come from regulations.

Some come from contracts.

Some come from customer agreements.

Some come from privacy commitments.

Some come from industries in which the organization has chosen to operate.

And sometimes different obligations apply to different parts of the same enterprise.

NIST explicitly includes legal, regulatory, and contractual cybersecurity requirements within Organizational Context.

That means a mature cybersecurity governance program needs more than a list of security controls.

It needs to understand the obligations those controls are supposed to satisfy.

Imagine a company proudly reports:

“We encrypt sensitive information.”

Good.

Which sensitive information?

Because of which requirement?

Who is responsible for that requirement?

What systems contain the information?

Does the requirement extend to third parties?

What evidence demonstrates that encryption is actually operating as intended?

What happens when an exception exists?

Suddenly a technical control becomes part of a much larger governance chain.

The obligation gives the control context.

What Cannot Stop?

Here is another deceptively simple question:

What does your organization absolutely have to keep doing?

For a manufacturer, it might be production.

For a bank, transaction processing.

For a hospital, patient care.

For an airline, safe flight operations.

For a municipality, emergency services or water delivery.

For an online retailer, order processing and fulfillment.

For a small professional services firm, it might simply be email, customer records, billing, and access to its cloud applications.

Size does not eliminate the question.

NIST asks organizations to understand and communicate the critical objectives, capabilities, and services upon which stakeholders depend.

That word critical matters.

Cybersecurity programs operate with finite resources.

There is never unlimited money.

Never unlimited staff.

Never unlimited time.

Never unlimited executive attention.

So governance requires prioritization.

And you cannot prioritize intelligently until you know what the organization cannot afford to lose.

Then Ask the Question Organizations Often Forget

What do you depend on?

This is the other side of Organizational Context.

Your organization may provide a critical service.

But what has to work for you to provide it?

Cloud platforms.

Telecommunications.

Payment processors.

Software providers.

Managed service providers.

Identity systems.

Data centers.

Electricity.

Logistics companies.

Specialized suppliers.

A particular manufacturing facility.

Perhaps even one employee who understands an obscure but business-critical system nobody else knows how to operate.

Modern organizations are networks of dependencies.

Some are obvious.

Others remain invisible until they fail.

NIST’s implementation guidance for GV.OC specifically points organizations toward inventorying dependencies on external resources and identifying those that could become points of failure for critical capabilities and services.

That is not merely a cybersecurity exercise.

It is an exercise in understanding how the business actually works.

Follow the Business Service Backward

One of the most useful ways to understand cyber risk is to stop beginning with technology.

Begin with a business outcome.

Suppose the outcome is:

Customers can place orders.

Now work backward.

What business process enables that?

What applications support the process?

What data does it require?

Where is that data stored?

What identities and credentials provide access?

What infrastructure supports the applications?

What cloud services are involved?

What networks must remain available?

What third parties participate?

What people are required?

What happens if any of those dependencies fail?

Now you are no longer looking at an inventory of technology.

You are looking at a business service and the chain of dependencies that makes it possible.

That is much closer to how cybersecurity risk should be understood.

Why Asset Inventories Alone Are Not Enough

Security professionals have spent years emphasizing asset inventories, and rightly so.

You cannot protect technology you do not know exists.

But knowing that an organization has 8,000 endpoints, 600 servers, 140 applications, and 37 SaaS platforms still does not tell leadership what matters most.

An inventory tells you what exists.

Context tells you why it matters.

That distinction becomes critical during prioritization.

Suppose the security team identifies 2,000 vulnerabilities.

Which ones should be fixed first?

“Critical severity” may help narrow the list.

Internet exposure may narrow it further.

Known exploitation may change the priority again.

But there is still another dimension:

What business capability is attached to the vulnerable asset?

A vulnerability affecting infrastructure supporting a critical revenue process may warrant a very different response from an identical vulnerability on an isolated low-value system.

The technical facts inform the decision.

Business context determines its consequence.

The Dashboard Problem

This brings us to one of the persistent weaknesses in executive cybersecurity reporting.

Many dashboards tell leadership what Security can measure.

Number of vulnerabilities.

Phishing click rates.

Endpoint coverage.

Patch compliance.

Mean time to detect.

Mean time to respond.

Security incidents.

These can all be useful operational measures.

But imagine a director asking:

Which of our five most important business services currently has the greatest cyber exposure?

Can the dashboard answer?

Or:

Which critical business capability depends on a supplier whose failure could materially disrupt us?

Can it answer that?

Or:

Which regulatory or contractual obligations are currently exposed because a cybersecurity control is not performing as intended?

Can it answer that?

If not, leadership may have a cybersecurity dashboard without having a meaningful view of cybersecurity risk.

The missing ingredient is organizational context.

Cybersecurity Risk Is Business Risk With a Cyber Cause

This is the conceptual shift I want readers to take from this installment.

Cyber risk is sometimes described in technical language because the initiating condition is technical.

A vulnerability.

A compromised account.

Malware.

A cloud misconfiguration.

A failed control.

But organizations do not ultimately experience vulnerabilities.

They experience consequences.

Operations stop.

Revenue is lost.

Data is exposed.

Customers leave.

Contracts are breached.

Regulators investigate.

Safety may be affected.

Reputation deteriorates.

Strategic objectives are delayed.

That is why cybersecurity risk cannot be governed intelligently in isolation from the business.

The cyber event is the cause.

The business consequence is the risk leadership must understand.

Five Questions Tell You a Great Deal

You do not need to begin Organizational Context with a 200-page assessment.

Start with five questions.

What are we here to accomplish?

That is mission.

Who depends on us, and what do they expect from us?

Those are stakeholders.

What cybersecurity obligations have we assumed?

Those are legal, regulatory, contractual, and other requirements.

Which capabilities and services absolutely must continue?

Those are critical business outcomes.

What do we depend upon to deliver them?

Those are dependencies.

Those five questions closely reflect the five outcomes NIST places beneath GV.OC.

And if an organization cannot answer them clearly, it is going to have difficulty answering almost every cybersecurity governance question that follows.

Governance Starts With Understanding What Matters

The goal of cybersecurity is not to make every system equally secure.

That would be economically impossible and operationally unnecessary.

The goal is to manage cybersecurity risk in a manner consistent with what the organization is trying to accomplish.

That requires context.

Before deciding how much risk to accept, understand what is at risk.

Before deciding what to protect, understand what matters.

Before deciding which vulnerability comes first, understand what depends on the affected system.

Before evaluating a supplier, understand what happens to your business if that supplier fails.

Before designing the cybersecurity dashboard for the board, understand which business outcomes the board is actually responsible for overseeing.

Technology does not provide those answers.

The business does.

And that is why you cannot govern cyber risk without understanding the business first.

In the next installment, we move from understanding what matters to one of the hardest governance questions leadership has to answer:

How much cybersecurity risk are we actually willing to accept?