, , ,

Cybersecurity Accountability Cannot End With “IT Owns It”

Cybersecurity accountability cannot simply be assigned to IT. Managing technology, making risk decisions, and owning business consequences require different roles, authorities, and accountabilities.

TCGB hero image showing executives in a boardroom viewing a shared cybersecurity accountability model connecting the board, executive leadership, business units, IT, security, legal, and risk.

GOVERN: Cybersecurity Governance in Plain English

Summary:

Part 4 of GOVERN: Cybersecurity Governance in Plain English explores Roles, Responsibilities, and Authorities (GV.RR) within NIST CSF 2.0. It distinguishes responsibility, authority, and accountability; examines why cyber risk belongs to the enterprise rather than IT alone; and explains how decision rights, escalation thresholds, resources, board oversight, and evidence create a defensible chain of accountability.

Part 4 of the TCGB Subscriber Series

Something goes wrong.

Customer data is exposed.

Production stops.

A critical supplier suffers a cyberattack.

An employee falls for a phishing attack.

A vulnerability that everyone knew about is exploited.

An AI system exposes confidential information.

Then someone asks:

Who owned this?

And somewhere in the conversation comes the answer:

“IT.”

That may be one of the most dangerous answers in cybersecurity governance.

Not because IT has no cybersecurity responsibilities.

It has many.

Not because the security team isn’t accountable for performing its assigned duties.

It is.

The problem is that performing cybersecurity work and owning cybersecurity risk are not the same thing.

That distinction sits at the heart of the third Category within the GOVERN Function of the NIST Cybersecurity Framework 2.0:

Roles, Responsibilities, and Authorities — GV.RR.

In plain English:

Who is responsible for doing what?

Who has authority to make which decisions?

Who needs to be informed?

And who is ultimately accountable for the outcome?

Those questions sound simple.

During a crisis, they rarely are.

Let’s Start With a Vulnerability

Return to the scenario from Part 3.

Security discovers a critical vulnerability in a production system.

The security team evaluates it.

The threat is credible.

The vulnerability could allow an attacker to compromise an important business service.

Security recommends immediate remediation.

Operations says remediation requires shutting the system down.

The outage could interrupt production for eight hours.

Finance estimates the potential loss.

Legal identifies contractual obligations.

The business executive responsible for the operation is concerned about customer commitments.

Now ask:

Who owns the vulnerability?

Security?

IT?

Operations?

The business executive?

The CIO?

The CISO?

The CEO?

The question itself may be wrong.

Different people own different parts of the problem.

Security may own vulnerability identification and assessment.

IT may own remediation activity.

Operations may own the affected business process.

A business executive may own the operational consequence.

Legal may own interpretation of contractual obligations.

Someone else may possess authority to accept the residual risk.

The board may have oversight responsibility if the exposure is sufficiently material.

One cyber risk.

Multiple responsibilities.

Different authorities.

Different accountabilities.

That is why “IT owns it” is inadequate.

Responsibility Is Not Authority

This is one of the most important distinctions in governance.

An individual can be responsible for something without having authority to make every decision associated with it.

Suppose a vulnerability management team is responsible for identifying and tracking vulnerabilities.

It discovers a serious exposure.

Can the team shut down the affected manufacturing system?

Probably not.

Can the CISO?

Maybe.

Can the CIO?

Perhaps.

Can the plant manager refuse?

Possibly.

Who breaks the tie?

That is an authority question.

Organizations frequently document responsibilities while leaving authority ambiguous.

A policy might say:

“The Information Security Department is responsible for managing cybersecurity risk.”

That sentence sounds authoritative.

But what does it actually mean?

Can Information Security prevent a product launch?

Can it reject a vendor selected by a business unit?

Can it require a production outage?

Can it prohibit an executive from using a particular technology?

Can it accept a $10 million residual risk?

Can it authorize paying a ransom?

Can it determine whether an incident must be disclosed?

The answers may differ.

And they should be defined before the organization is forced to discover them under pressure.

Accountability Is Different Again

Responsibility answers:

Who performs the work?

Authority answers:

Who can make the decision?

Accountability answers:

Who answers for the outcome?

Those three concepts overlap, but they are not interchangeable.

Imagine a business unit chooses to deploy a SaaS platform.

Security assesses the vendor and identifies several concerns.

The business decides the strategic benefit outweighs the risk.

An authorized executive approves an exception.

IT integrates the service.

Security monitors the relevant controls.

Six months later, the SaaS provider suffers a breach.

Who is accountable?

It would be difficult to argue that Security owns the entire outcome simply because cybersecurity was involved.

Security performed an assessment.

Security communicated the risk.

Security may have recommended additional safeguards.

The business made a decision.

Someone authorized the exception.

Governance should preserve that chain of accountability.

Otherwise, the organization creates an unfortunate pattern:

The business owns the upside.

IT owns the downside.

That is not governance.

Cyber Risk Belongs to the Enterprise

Cybersecurity risk is often generated by business activity.

Organizations adopt cloud platforms.

Launch digital products.

Collect customer data.

Connect operational systems.

Hire vendors.

Acquire companies.

Deploy AI.

Enable remote work.

Integrate supply chains.

Enter new markets.

Those activities create value.

They also create cyber risk.

Security did not create the business objective.

Security helps the organization understand and manage the risk associated with pursuing it.

This is why saying “cyber risk belongs to the CISO” can be misleading.

The CISO has an important role.

The CISO may own the cybersecurity program.

The CISO may own security strategy.

The CISO may be responsible for controls, monitoring, incident response, and risk reporting.

But the CISO does not own every business consequence arising from cyber risk.

The enterprise does.

NIST Makes Roles and Authority Part of GOVERN

NIST CSF 2.0 treats roles, responsibilities, and authorities as explicit governance outcomes.

Within GV.RR, organizations are expected to establish, communicate, understand, and enforce cybersecurity-related roles, responsibilities, and authorities.

NIST also addresses accountability for cybersecurity risk management and performance assessment.

It includes adequate resources for cybersecurity strategy, roles, responsibilities, and policies.

And importantly, it addresses cybersecurity as part of human resources practices.

That tells us something important.

Governance is not satisfied by drawing an organizational chart.

People need to understand what is expected of them.

They need sufficient authority to fulfill those expectations.

They need appropriate resources.

And the organization needs mechanisms for holding them accountable.

Decision Rights Matter Before the Crisis

Consider ransomware.

An attacker has encrypted systems supporting a critical operation.

The incident-response team recommends isolating additional systems.

Doing so could stop the business.

Who can authorize that?

Now the attacker demands payment.

Who can authorize negotiations?

Who can authorize payment?

Who determines whether law enforcement is contacted?

Who decides whether customers are notified?

Who determines whether regulators must be informed?

Who communicates with employees?

Who speaks publicly?

Who briefs the board?

Who decides when systems can return to production?

Those decisions may involve:

Security.

IT.

Legal.

Finance.

Operations.

Communications.

Executive management.

The board.

Insurers.

Outside counsel.

Incident-response providers.

Law enforcement.

Perhaps regulators.

The middle of a ransomware incident is a terrible time to begin debating decision rights.

Governance should have answered those questions beforehand.

The Same Problem Appears Without an Incident

Ambiguous authority is not merely an incident-response problem.

It appears in ordinary business decisions.

Marketing wants a new customer analytics platform.

Security objects to the vendor’s data-handling practices.

Who decides?

Engineering wants to release software despite unresolved security defects.

Who decides?

Operations wants to delay a security update because downtime would interrupt production.

Who decides?

A senior executive wants an exception from multifactor authentication because it creates inconvenience.

Who decides?

A business unit wants to use a generative AI service with confidential information.

Who decides?

Procurement wants to sign a contract before the security review is complete.

Who decides?

These decisions happen every day.

If the answer depends primarily on organizational politics, persistence, or which executive has the most influence, then the organization does not have defined decision rights.

It has negotiation.

“The Business Owns the Risk” Can Be Just as Bad

Cybersecurity professionals sometimes respond to the “IT owns it” problem with another phrase:

“The business owns the risk.”

That is directionally better.

But it can still be too vague.

Who in the business?

The product manager?

Department head?

Business-unit president?

Chief Operating Officer?

Chief Risk Officer?

CEO?

Board?

“The business” cannot sign an exception.

“The business” cannot testify.

“The business” cannot explain why a decision was made.

People make decisions.

Governance should identify them.

If a particular executive has authority to accept a certain category and magnitude of cyber risk, say so.

If risks above a threshold require escalation, define the threshold.

If certain risks can never be accepted at that level, establish the boundary.

Accountability becomes meaningful when it has a name, a role, and defined authority.

Authority Should Follow Consequence

One useful principle is:

The greater the potential enterprise consequence, the higher the decision should travel.

A department manager may reasonably accept a small temporary operational risk.

That same manager probably should not have unilateral authority to accept a cyber risk capable of exposing millions of customer records.

A CIO may have authority to accept certain technology risks.

That does not necessarily mean the CIO should independently accept a risk capable of materially affecting the company’s financial position.

Executive management may make significant enterprise risk decisions.

Some risks may require board visibility or oversight.

The objective is not to escalate everything.

That would paralyze the organization.

The objective is to establish proportional decision rights.

Routine risks remain close to operations.

Significant risks move upward.

Material risks receive appropriate executive and board attention.

Good governance creates that path before it is needed.

Accountability Without Resources Is Theater

There is another side to this discussion.

Organizations sometimes assign responsibility without providing the resources necessary to fulfill it.

A CISO is told:

“You are responsible for cybersecurity.”

But the security program is understaffed.

Critical systems cannot be replaced.

Business units can ignore security recommendations.

Security has no authority over vendor selection.

Remediation budgets are controlled elsewhere.

Known risks remain unresolved because operating groups prioritize other work.

Then an incident occurs.

Leadership asks:

“Why didn’t the CISO prevent this?”

That is not accountability.

That is scapegoating.

NIST’s inclusion of resources within GV.RR matters for exactly this reason.

Responsibility, authority, and resources have to be reasonably aligned.

If someone is accountable for an outcome but lacks the authority or resources necessary to influence it, the governance design is defective.

The Board Has Responsibilities Too

Board oversight does not mean directors operate the cybersecurity program.

They should not.

But cybersecurity accountability does not stop at management.

The board has its own governance responsibilities.

Is management operating within established risk boundaries?

Are material cyber risks reaching the board?

Does the board receive information sufficient to exercise oversight?

Are responsibilities between management and the board clear?

Does management have the capabilities and resources necessary to manage the risks the organization is taking?

Are significant exceptions being handled appropriately?

Is cybersecurity integrated into enterprise risk discussions?

The board does not need to decide which endpoint platform to purchase.

It does need to understand whether management has established an effective system for making and overseeing consequential cyber risk decisions.

That is the difference between governance and management.

A RACI Chart Won’t Save You

Many organizations use RACI matrices:

Responsible.

Accountable.

Consulted.

Informed.

They can be useful.

But a beautifully formatted matrix does not create governance.

The real test comes when two legitimate organizational objectives conflict.

Security says stop.

Operations says continue.

Who decides?

The CISO recommends rejecting a supplier.

The business sponsor wants to proceed.

Who decides?

An incident threatens both business continuity and regulatory exposure.

Who decides?

If the answer cannot be derived from the organization’s governance model, the RACI chart is documentation—not authority.

The question isn’t whether roles have been written down.

The question is whether those roles actually govern decisions.

Follow the Decision

There is a simple exercise organizations can perform.

Take one significant cyber risk.

Then follow the decision.

Who identified it?

Who assessed it?

Who recommended the response?

Who owns the affected business process?

Who owns remediation?

Who can approve an exception?

Who accepts the residual risk?

Who determines whether escalation is required?

Who receives the information?

Who monitors the decision?

Who verifies that the agreed action occurred?

Who answers if the risk materializes?

If the chain breaks anywhere, you have probably found a governance gap.

Evidence Matters Here Too

There is another reason defined accountability matters.

Months or years after a decision, someone may ask what happened.

An auditor.

A regulator.

An insurer.

A customer.

Outside counsel.

The board.

Perhaps a court.

The question may not simply be:

“Did you know about the risk?”

It may become:

Who knew?

When did they know?

What did they recommend?

Who had authority?

What decision was made?

Why?

What exception was approved?

What compensating controls were required?

Who accepted the residual risk?

Was the decision reviewed?

Was the required action completed?

Good governance leaves evidence.

Not because every decision should be made defensively.

But because consequential decisions should be reconstructable.

If nobody can determine who made a significant cyber risk decision six months after it occurred, accountability existed only in theory.

Five Questions Expose the Problem Quickly

Leadership can learn a great deal by asking five questions.

Who owns the business consequence if this cyber risk materializes?

Not merely the technology.

The consequence.

Who is responsible for managing the risk?

That identifies operational responsibility.

Who has authority to accept the residual risk?

That identifies decision rights.

At what point must the decision be escalated?

That identifies governance boundaries.

What evidence shows who decided what?

That establishes accountability.

If the answers repeatedly end with “IT,” look deeper.

IT Owns Technology. The Enterprise Owns Consequence.

IT and Security have critical responsibilities.

They should be held accountable for performing those responsibilities effectively.

But cybersecurity governance fails when every cyber-related consequence is pushed downward into the technology organization.

The business chooses objectives.

The organization takes risk to pursue them.

Technology enables those choices.

Cybersecurity informs and manages part of the resulting risk.

Leadership establishes boundaries.

Authorized people make decisions.

The board provides oversight.

And the enterprise owns the consequences.

That is a much more accurate accountability model than:

“IT owns cybersecurity.”

Because when a consequential cyber decision goes wrong, the most important question is rarely:

Who owned the server?

It is:

Who owned the decision?

That is the question GV.RR forces organizations to answer.

And once we know who is responsible, who has authority, and who is accountable, we encounter another governance challenge:

What rules are those people expected to follow—and how does leadership know those rules are actually being followed?

That is where we go next in Part 5:

A Cybersecurity Policy Is Not Governance Until Someone Enforces It.


Back to Articles

Not sure where your governance posture stands? Start Readiness Self-Assessment