Your Cybersecurity Governance Boundary Does Not Stop at Your Firewall

GOVERN: Cybersecurity Governance in Plain English

Part 6 of the TCGB Subscriber Series

Your organization probably does not control most of the technology it depends upon.

Think about that for a moment.

Your email may run in someone else’s cloud.

Your customer data may live inside someone else’s software.

Your employees may authenticate through someone else’s identity platform.

Your payments may travel through someone else’s infrastructure.

Your website may depend on third-party code.

Your security operations may rely on an outside provider.

Your backups may reside in another company’s data centers.

Your software may contain hundreds or thousands of components written by people you have never met.

Your AI systems may depend on models you did not build, running on infrastructure you do not own, processing data through services you cannot inspect.

Yet when one of those dependencies fails, your customers will probably not say:

“That’s all right. It was your vendor.”

They will say:

“What happened to your service?”

That distinction brings us to the sixth and final Category within the GOVERN Function of the NIST Cybersecurity Framework 2.0:

Cybersecurity Supply Chain Risk Management — GV.SC.

And it brings us to the final lesson of this series.

You can outsource technology.

You can outsource operations.

You can outsource cybersecurity services.

You cannot outsource accountability for the business risk those dependencies create.

The Modern Enterprise Has No Real Perimeter

For years, cybersecurity was commonly described using the language of boundaries.

Inside the network.

Outside the network.

Trusted.

Untrusted.

Behind the firewall.

Beyond the firewall.

That model was always imperfect.

Today it is increasingly inadequate.

The modern organization is an ecosystem.

Cloud providers.

Software-as-a-Service platforms.

Managed service providers.

Payment processors.

Telecommunications providers.

Data processors.

Software suppliers.

Contractors.

Consultants.

Business partners.

Logistics companies.

Critical infrastructure providers.

AI platforms.

Open-source software.

Application programming interfaces.

Fourth parties you may not even know exist.

The technology supporting your organization may cross dozens of organizational boundaries before a customer sees the final service.

The firewall never contained that ecosystem.

Your governance model shouldn’t pretend that it does.

Start With a Simple Question

Choose one critical business service.

Perhaps:

Customers can place orders.

Now ask:

What has to work for that statement to remain true?

Your website.

DNS.

Cloud infrastructure.

Identity services.

Databases.

Payment processing.

Inventory systems.

APIs.

Telecommunications.

Warehouse systems.

Shipping providers.

Perhaps fraud detection.

Perhaps customer communications.

Perhaps a SaaS commerce platform.

Perhaps dozens of software libraries.

Now ask a more difficult question:

Which of those dependencies does your organization actually control?

Probably fewer than you think.

This is why supply chain cybersecurity belongs inside GOVERN.

The organization needs a deliberate strategy for managing cyber risk that originates outside its direct control.

A Vendor Can Become Your Incident

Suppose your payroll provider suffers ransomware.

Your network was not compromised.

Your systems were not attacked.

Your security team did nothing wrong.

But employees cannot be paid.

Do you have a cyber problem?

Of course.

Suppose a cloud provider experiences an outage.

Your infrastructure is functioning exactly as designed.

But customers cannot access your service.

Do you have a resilience problem?

Absolutely.

Suppose a software supplier distributes a compromised update.

Your organization installs legitimate software obtained through an approved process.

The software introduces an attacker into your environment.

Whose cyber incident is it now?

Yours.

The origin of the failure may belong to the supplier.

The business consequence belongs to you.

That is the governance problem.

“They Passed Our Vendor Assessment” Is Not Enough

Third-party cybersecurity programs often become assessment factories.

Send questionnaire.

Receive questionnaire.

Score questionnaire.

Request documentation.

Assign risk rating.

Approve vendor.

File assessment.

Repeat next year.

There is value in due diligence.

But completing an assessment does not govern the dependency.

Suppose the vendor checked every box.

Then six months later:

Its environment changes.

Your use of the service expands.

You begin storing more sensitive information there.

The vendor acquires another company.

It changes subprocessors.

Its security leadership changes.

A vulnerability is discovered in its product.

Its financial condition deteriorates.

It suffers an incident.

The threat landscape changes.

Your own business becomes more dependent upon the service.

The assessment is still sitting in the file.

The risk has moved.

Governance has to move with it.

NIST Treats Supply Chain Risk as a Governance Responsibility

NIST CSF 2.0 places Cybersecurity Supply Chain Risk Management directly inside GOVERN.

That placement is significant.

GV.SC addresses establishing a cybersecurity supply chain risk-management program, strategy, objectives, policies, and processes.

It addresses defining roles and responsibilities.

It calls for integrating supply chain risk into cybersecurity and enterprise risk management.

It addresses identifying and prioritizing suppliers according to criticality.

It addresses establishing cybersecurity requirements for suppliers.

It addresses due diligence before entering formal relationships.

It addresses understanding and responding to supplier risk throughout the relationship.

It addresses including suppliers in incident planning, response, and recovery where appropriate.

And it addresses what happens when the relationship ends.

This is not simply vendor assessment.

It is lifecycle governance.

Not Every Vendor Deserves the Same Scrutiny

Your office coffee supplier and your cloud identity provider are both vendors.

They are not equivalent cyber risks.

This sounds obvious.

Yet many third-party risk programs still treat vendors primarily according to standardized review procedures rather than business dependency.

A better starting point is:

What happens to us if this supplier fails?

Can we continue operating?

How quickly?

What data does the supplier possess?

What systems can it access?

Can compromise of the supplier provide a path into our environment?

Does the supplier support a critical business service?

Can it be replaced?

How long would replacement take?

Do we have alternatives?

Could its failure create regulatory or contractual exposure?

Could it affect safety?

Could it materially affect customers?

Those questions reveal criticality.

And criticality should influence governance.

Follow the Dependency, Not Just the Contract

Imagine a SaaS platform supports a critical business process.

Your organization assesses the provider.

Good.

But the provider runs on a major cloud platform.

It uses another company for identity services.

Another for payment processing.

Several subprocessors handle data.

Its software includes open-source components.

Its customer-support operation is outsourced.

Your direct contract is with one company.

Your operational dependency may extend through many.

This is the fourth-party problem.

And fifth-party.

And eventually the terminology becomes less useful than the underlying reality:

You depend on an ecosystem you cannot completely see.

No organization can investigate every supplier of every supplier indefinitely.

Governance therefore requires prioritization.

Where are the concentrations?

Where are the single points of failure?

Which dependencies support critical services?

Which external relationships create the greatest potential enterprise consequence?

Those deserve disproportionate attention.

Concentration Risk Is Easy to Miss

Suppose ten critical applications use the same cloud provider.

Individually, each application has a documented recovery plan.

Looks good.

But what happens if the common cloud dependency fails?

Or twenty important vendors rely on the same identity provider?

Or multiple business units independently purchase services from companies running on the same underlying infrastructure?

On paper, you may have diversified suppliers.

Operationally, you may have concentrated risk.

This is why Organizational Context from Part 2 matters here.

You cannot govern supply chain risk simply by counting vendors.

You need to understand how external dependencies connect to critical business services.

The unit of analysis is not merely the supplier.

It is the business consequence created by dependence on the supplier.

Contracts Matter, But Contracts Do Not Stop Incidents

Contracts are an important governance mechanism.

Organizations may establish requirements covering:

Security controls.

Incident notification.

Data protection.

Audit rights.

Subprocessors.

Vulnerability management.

Business continuity.

Recovery.

Cyber insurance.

Data return or destruction.

Termination.

Cooperation during investigations.

These provisions matter.

But there is a dangerous temptation to confuse contractual transfer with actual risk transfer.

Suppose your contract requires a supplier to notify you of a cyber incident within 24 hours.

Excellent.

The supplier suffers an incident and complies perfectly.

Your service is still unavailable.

Your customers are still affected.

Your operations are still disrupted.

The contract may help determine liability.

It does not restore the service.

Legal allocation of responsibility and operational resilience are different things.

Governance needs both.

Cyber Insurance Does Not Make the Risk Disappear Either

The same principle applies to insurance.

Insurance can transfer some financial consequences.

It cannot transfer every consequence.

A policy may help cover response costs.

It cannot restore customer trust automatically.

It cannot undo exposed information.

It cannot reverse a safety event.

It cannot guarantee regulatory outcomes.

It cannot make a critical supplier available.

And insurance itself increasingly depends on representations about controls, governance, and risk-management practices.

Risk transfer is a strategy.

It is not risk elimination.

The Supplier Needs to Be in the Incident Plan

There is a simple question organizations should ask about every critical technology supplier:

If this company has a major cyber incident tonight, what do we do tomorrow morning?

Who contacts the supplier?

Who receives notifications?

Who determines whether your organization is affected?

What information is required?

Can you isolate the supplier from your environment?

Can you operate without the service?

For how long?

Who communicates with customers?

Does Legal need to act?

Are regulators involved?

Does the board need notification?

What contractual rights can be exercised?

What alternatives exist?

How will recovery be coordinated?

If the first time your incident-response team sees the vendor contract is during the incident, supplier governance has failed somewhere upstream.

NIST’s inclusion of suppliers in incident planning, response, and recovery is therefore particularly important.

Critical dependencies need to be incorporated into operational resilience before they fail.

Your Supplier’s Recovery Time Becomes Your Recovery Time

Suppose your business requires a critical service to recover within four hours.

Your internal recovery plans support that objective.

Excellent.

The SaaS provider supporting the service contractually commits to recovery within 24 hours.

You do not have a four-hour recovery capability.

You have a 24-hour dependency.

This is where cybersecurity, business continuity, resilience, procurement, and governance intersect.

The business requirement has to flow through the dependency chain.

If the organization requires a particular level of resilience, critical suppliers need to support it—or leadership needs to knowingly accept the gap.

Again, someone has to decide.

The themes from the entire series keep returning.

What Happens When the Relationship Ends?

Third-party governance often focuses heavily on onboarding.

Assessment completed.

Contract signed.

Vendor approved.

But relationships end.

What happens then?

Does the supplier still possess your data?

Are accounts disabled?

Are API keys revoked?

Are integrations removed?

Are certificates invalidated?

Are privileged credentials changed?

Is equipment returned?

Is data deleted or returned?

Can the supplier demonstrate destruction where required?

Do subcontractors retain copies?

Has access actually ended?

A supplier that no longer appears in the procurement system can still create cybersecurity exposure.

NIST explicitly includes activities after the conclusion of a supplier relationship within GV.SC.

The lifecycle does not end when Accounts Payable stops receiving invoices.

AI Makes This Problem Even More Interesting

Artificial intelligence is accelerating the dependency problem.

An organization may purchase an AI-enabled application from one vendor.

That application may use another company’s foundation model.

The model may run in another cloud environment.

Data may pass through additional services.

Retrieval systems may connect to enterprise repositories.

Agents may interact with external APIs.

Plugins may extend functionality.

Models may change without traditional software release cycles.

Suddenly the question:

“Who is our AI vendor?”

may have several answers.

Governance must follow the actual dependency architecture, not merely the logo on the contract.

The same principles still apply.

What business outcome depends on the service?

What information does it access?

What decisions can it influence?

What external dependencies exist?

What happens if one fails?

Who owns the resulting risk?

Supply Chain Governance Is Really Dependency Governance

This is the broader lesson.

“Supply chain” can make us think about manufacturers, components, and physical suppliers.

But cybersecurity supply chain risk is fundamentally about dependency.

Who and what must function for your organization to accomplish its mission?

Some dependencies are internal.

Many are external.

Some are contractual.

Some are technical.

Some are invisible.

Some are concentrated.

Some are replaceable.

Some are not.

Good governance makes the important dependencies visible and manages them according to the consequences their failure could create.

Six Questions for Every Critical Supplier

For a critical supplier, leadership should be able to answer:

What business service depends on this supplier?

That establishes context.

What happens to us if the supplier is compromised or unavailable?

That establishes consequence.

What cybersecurity and resilience expectations have we established?

That establishes requirements.

Who owns the supplier risk inside our organization?

That establishes accountability.

How do we know the supplier continues to meet our expectations?

That establishes oversight.

What is our plan if the supplier cannot deliver?

That establishes resilience.

Notice what just happened.

Those six questions brought us back through nearly the entire GOVERN Function.

That is not accidental.

GOVERN Is a System

We began this series with a simple question:

Who is accountable?

Then we built outward.

Organizational Context asked:

What matters to the business?

Risk Management Strategy asked:

How much risk are we willing to accept?

Roles, Responsibilities, and Authorities asked:

Who does what, who decides, and who answers for the outcome?

Policy asked:

What rules and expectations have we established?

Oversight asked:

How do we know the system is actually working?

And now Cybersecurity Supply Chain Risk Management asks:

How do we extend that governance across the organizations and technologies upon which we depend?

These are not six unrelated administrative exercises.

Together they form a governance system.

Context → Risk → Accountability → Rules → Oversight → Ecosystem

That is GOVERN in plain English.

Your Firewall Was Never the Governance Boundary

A company can outsource its email.

Its infrastructure.

Its applications.

Its payroll.

Its security monitoring.

Its data processing.

Its software development.

Its customer support.

Its AI capabilities.

Perhaps nearly every technological capability it possesses.

But one thing remains.

Accountability.

When a critical supplier fails, your organization still has customers.

Still has employees.

Still has contractual commitments.

Still has regulators.

Still has shareholders or stakeholders.

Still has a mission.

Still has consequences.

The supplier may own the incident.

Your organization owns its dependence on the supplier.

That is why cybersecurity governance cannot stop at the firewall.

It has to follow the business.

It has to follow the data.

It has to follow the technology.

It has to follow the decision.

And increasingly, it has to follow the dependency.

Wherever the consequence can reach your organization, governance has to reach there too.

A Note to TCGB Subscribers

If you have followed all six installments, thank you.

I created this series specifically for this subscriber community because cybersecurity governance should not require a standards manual and a dictionary to understand.

The underlying questions are profoundly practical:

What matters?

What could go wrong?

How much risk are we willing to accept?

Who decides?

Who is accountable?

What rules have we established?

How do we know they are being followed?

And what happens when the organizations we depend upon fail?

NIST gives us a framework.

Governance gives that framework consequence.

And perhaps the most important lesson from these six articles is this:

Cybersecurity governance is not primarily about technology.

It is about how an organization makes consequential decisions about technology-enabled risk.

That is the conversation I want The Cyber Governance Brief to continue having with you.

Thank you for subscribing—and for being part of it.