NIST CSF 2.0 GV.OC-05: Map What You Depend On

GV.OC-05 says the outcomes, capabilities and services that the organization depends on are understood and communicated. Where GV.OC-04 looks at what others expect from you, this one looks the other way: what you rely on from others. That includes cloud hosts, payment and email providers, facilities, and the open source packages inside your own software.

What good looks like

You can answer, quickly, which outside services your critical capabilities need and what happens if one disappears. The inventory links each dependency to the business function it supports. The riskiest ones, the single points of failure, are known to the people who would have to respond.

NIST's examples ask for two things: an inventory of external dependencies and their relationship to your assets and business functions, and documentation of those that are potential points of failure, shared with appropriate personnel.

How to implement it

1. Start from the critical services you identified under GV.OC-04. For each, list every outside thing it needs to run: hosting, identity provider, DNS, payments, messaging, data feeds, support tools.
2. Add software dependencies. Your applications pull in direct and transitive packages. A software bill of materials gives you that list automatically from your build or repository.
3. Record for each dependency: owner internally, what it supports, whether a substitute exists, and how long you could operate without it.
4. Mark single points of failure. One DNS provider, one region, one maintainer of a key package.
5. Share the result with incident responders and the people who negotiate contracts.
6. Refresh it when you add a vendor or ship a major release.

Software dependencies are part of this

Open source packages are suppliers too, just ones you never signed with. A short generated inventory of packages, versions and known vulnerabilities turns a vague worry into a list. You can try this without connecting a repository using the free in-browser dependency scan at https://gold.safeguard.sh/scan. Reachability analysis then helps separate vulnerable packages your code actually calls from ones that sit unused.

Evidence to collect

• The dependency inventory with function mappings and owners.
• The single point of failure list with mitigation notes.
• A software bill of materials for each critical application, with generation dates.
• Evidence of sharing, such as a runbook that links to the inventory.

Common gaps

• The inventory lists vendors but ignores open source components.
• Fourth parties are invisible: your provider depends on a provider.
• The list is built once for an audit and never updated.
• Nobody has checked whether the substitute you wrote down actually works.

Generating a bill of materials

The demo below shows how a software bill of materials is generated from a project, which is the quickest way to cover the software half of this outcome.

A worked example

Picture a twenty person company with one customer facing web app. Its dependency inventory has four layers. Facilities: a coworking office and no server room. Infrastructure: one cloud provider in one region, one DNS host, one identity provider. Services: a payment processor, an email delivery service, an error tracker. Software: about 600 packages across the app and its build tooling.

Walking the list as a team surfaces three single points of failure in an hour. The DNS host has no secondary. The email service sends password resets, so an outage locks users out. One internal library has a single maintainer who has not committed in two years. None of these is dramatic. All of them were invisible before the list existed.

Fourth parties

Your providers have providers. If your payment processor runs on the same cloud region as you, one regional outage can take out both. You will not see all of this, but ask your most important suppliers for their own hosting regions and critical subprocessors, and record the answers. Many publish them on a trust or status page.

Review rhythm

Refresh the inventory when you add or drop a vendor, when you ship a release that changes major dependencies, and at least twice a year. Generated inventories such as a software bill of materials can refresh on every build, which is the cheapest way to keep the software layer honest.

What to do with the list

An inventory only pays off when it changes something. Take the top three single points of failure and write a short plan for each: add a secondary provider, document a manual workaround, or accept the risk with a named approver and a review date. For software dependencies, set a rule for how new packages are added and who reviews critical ones, and track the share of components with known vulnerabilities over time.

Share the inventory with the people who will need it at 3 a.m. An incident responder who can see that the payment processor, the identity provider and the main database all sit in one region will make better decisions in the first ten minutes of an outage.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST Cybersecurity Framework 2.0 Reference Tool, subcategory GV.OC-05: https://csrc.nist.gov/projects/cybersecurity-framework/filters
• NIST Cybersecurity Framework overview: https://www.nist.gov/cyberframework

The CSF is voluntary guidance. There is no CSF certification, so this post describes how to work toward the outcome, not how to pass an audit.