NIST CSF 2.0 Govern: A Profile for Infrastructure You Own

Almost everything written about CSF 2.0 explains the framework: GOVERN is new, here is what changed from 1.1. NIST ships a blank Profile template, sector Community Profiles exist, GRC products will score Current against Target. What none contains is a filled GV.SC row set for an estate whose suppliers are a colocation contract, a hardware vendor, a storage cluster, and upstream projects with no counterparty.

This article builds that. It is a different job from NIST SP 800-53 on Kubernetes you own, published on 23 August 2026 — that maps a control catalogue onto cluster objects; this starts from an outcome framework naming no controls. Do the Profile first: it tells you which control families are worth the effort.

Govern is where self-hosting becomes a decision

CSF 2.0 organises outcomes under six Functions: "GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER". GOVERN is the addition, providing "outcomes to inform what an organization may do to achieve and prioritize the outcomes of the other five Functions". Among what it addresses by name: "the establishment of cybersecurity strategy and cybersecurity supply chain risk management".

The common mistake is reading that as supply chain risk arriving with 2.0. It did not. CSF 1.1, published 16 April 2018, already carried a Supply Chain Risk Management Category — ID.SC, under IDENTIFY — with five Subcategories, ID.SC-1 through ID.SC-5. Its Note to Readers: "a Supply Chain Risk Management Category, including multiple Subcategories, has been added to the Framework Core."

What 2.0 does is relocate and expand: out of IDENTIFY, into GOVERN as GV.SC, five Subcategories to ten. Under IDENTIFY, supply chain risk is an identification task a platform team performs and hands upward. Under GOVERN it sits with organisational context, risk strategy, roles, policy and oversight — a decision with an owner, not an inventory exercise.

That is where the case for running your own infrastructure is weakest on paper. The governance question is not whether the design is good but who decided this, on what basis, and what happens when it stops being true.

What GV.SC asks, and what a provider cannot answer for you

The Category outcome is one sentence: "Cyber supply chain risk management processes are identified, established, managed, monitored, and improved by organizational stakeholders." Appendix A lists ten Subcategories contiguously, GV.SC-01 through GV.SC-10. Five do most of the work for an infrastructure estate.

• GV.SC-04 — "Suppliers are known and prioritized by criticality". A ranked list, with the ranking basis written down.
• GV.SC-05 — requirements "integrated into contracts and other types of agreements with suppliers and other relevant third parties". Needs a counterparty.
• GV.SC-06 — due diligence "before entering into formal supplier or other third-party relationships". Before, not after the migration.
• GV.SC-07 — supplier risk "monitored over the course of the relationship". Continuous, not a questionnaire filed once.
• GV.SC-10 — plans "include provisions for activities that occur after the conclusion of a partnership or service agreement". The ending, planned during the relationship.

Against a hyperscaler estate a pattern appears. GV.SC-05 and GV.SC-06 are answerable by the provider's paperwork. GV.SC-04 collapses to one enormous row. GV.SC-07 degrades into reading a status page. And GV.SC-10 is the row nobody fills, because writing it down means costing the exit — see exit-cost modelling and data gravity.

NIST is blunt about where responsibility lands regardless. SP 800-161r1-upd1 states that outsourcing "reduces the acquirer's visibility into and control of the outsourced functions", then closes the door: "Regardless of who performs the services, the acquirer is ultimately responsible and accountable for the risk to the enterprise's systems and data."

Accountability does not transfer with the workload. Self-hosting changes the supplier list's shape: one counterparty answering everything opaquely becomes a dozen each answering one thing you can verify.

Scoping the Profile: your supplier list when you own the metal

Start with scope, because CSF 2.0 allows a narrow one: "An organization can have as many Organizational Profiles as desired, each with a different scope" — its own examples run down to "an organization's financial systems". An estate-scoped Profile is a legitimate use of the method.

Then build the register. NIST's companion Implementation Examples document, dated 26 February 2024, gives GV.SC-04 two examples, usable as-is. Ex1: criticality criteria based on "the sensitivity of data processed or possessed by suppliers, the degree of access to the organization's systems, and the importance of the products or services to the mission". Ex2: "Keep a record of all suppliers, and prioritize suppliers based on the criticality criteria". Ex1 is the fields; Ex2 is the file.

The extension a self-hosted estate needs is what most registers omit: the upstream projects the platform is made of — kernel, Kubernetes, CNI, Postgres, etcd. By Ex1's criteria they rank at the top, and they have no contract. The register below is a modelled example.

# supplier-register.yaml — GV.SC-04 evidence for an estate you operate.
# Scoring fields are Implementation Example GV.SC-04 Ex1; the file is Ex2.
criticality_criteria:
  data_sensitivity: [none, internal, confidential, regulated]
  access_degree: [none, network-adjacent, privileged-code, physical]
  mission_importance: [deferrable, degrading, halting]

suppliers:
  - id: colo-primary
    kind: colocation
    data_sensitivity: none          # they hold no data, they hold the room
    access_degree: physical
    mission_importance: halting
    agreement: master-services-agreement
    gv_sc_05_clauses: [notice-period, media-sanitisation, cage-handover]
    gv_sc_10_applies: true
    review: quarterly

  - id: hw-vendor
    kind: hardware-and-firmware
    access_degree: privileged-code  # firmware runs below everything you own
    mission_importance: halting
    agreement: purchase-and-support-contract
    gv_sc_05_clauses: [advisory-sla, signed-firmware, eol-notice]
    gv_sc_10_applies: true          # Ex2: component end-of-life planning
    review: quarterly

  - id: upstream-ceph
    kind: uncontracted-oss
    data_sensitivity: regulated     # it is the thing holding the bytes
    access_degree: privileged-code
    mission_importance: halting
    agreement: none                 # a licence is not a counterparty
    gv_sc_05_clauses: []            # nothing to negotiate with
    gv_sc_10_applies: false         # no agreement to conclude
    monitored_under: GV.SC-07
    operator_translation:           # NOT a NIST-asked outcome — see below
      mirror: registry.internal/mirror/ceph
      fork_readiness: docs/fork-readiness/ceph.md
      signals: [maintainer-concentration, release-cadence]
    review: monthly

The agreement field decides everything downstream. GV.SC-05 and GV.SC-10 both need a counterparty; an uncontracted upstream project has none, because a licence is not an agreement with someone. Those rows sit under GV.SC-04, monitored under GV.SC-07, and the mirror-and-fork planning is recorded as operator_translation so nobody is told NIST asked for a kernel exit clause.

Click to zoom

Building the Current Profile from artefacts you already have

NIST's Organizational Profiles quick-start guide, SP 1301 (February 2024), ships a spreadsheet that "facilitates side-by-side comparison of Current and Target Profiles to identify and analyze gaps". The YAML below does not replace it — it encodes the same layout so it lives in git beside the cluster and is validated by CI.

One distinction first. SP 1305, the C-SCRM quick-start guide, says you "can create as many Target Profiles as you need to specify the requirements for all of your suppliers". Those are supplier-facing requirement Profiles — documents you hand a supplier, a different artefact from the Organizational Profile you keep for the estate.

The discipline that makes a Current Profile survive is refusing prose where a pointer will do. "Access is reviewed regularly" is an assertion; a path to the audit policy in git plus the last review commit is evidence. Same evidence set SOC 2 on self-hosted Kubernetes and ISO 27001 without inherited controls draw on — build it once, point three regimes at it.

# profile-gv-sc.yaml — an engineering encoding of the SP 1301 side-by-side
# layout, scoped to the estate. Not a NIST-published format.
profile: { scope: "colocation, metal, Kubernetes, storage",
           tier_target: repeatable, cadence_days: 180, reviewed: 2026-08-25 }
rows:
  - { id: GV.SC-01, current: documented, target: "agreed by stakeholders",
      evidence: docs/governance/c-scrm-strategy.md }
  - { id: GV.SC-02, current: "two rows unassigned", target: "every row owned",
      evidence: docs/governance/raci.md }
  - { id: GV.SC-03, current: "not in ERM", target: "feeds enterprise register",
      evidence: docs/governance/risk-register.md }
  - { id: GV.SC-04, current: "contracted plus upstream", target: "ranked from SBOM",
      evidence: compliance/supplier-register.yaml }
  - { id: GV.SC-05, current: "colo and hardware clauses", target: "standard set at renewal",
      evidence: docs/procurement/clause-library.md }
  - { id: GV.SC-06, current: "ad hoc", target: "written pre-contract checklist",
      evidence: docs/procurement/due-diligence/ }
  - { id: GV.SC-07, current: "CVE feeds monthly", target: "advisory review logged per supplier",
      evidence: compliance/supplier-monitoring/ }
  - { id: GV.SC-08, current: "colo contact listed", target: "supplier failure in IR drills",
      evidence: docs/ir/scenarios/supplier-failure.md }
  - { id: GV.SC-09, current: "checks at admission", target: "no policy exemptions",
      evidence: policies/verify-images.yaml }
  - { id: GV.SC-10, current: "colo contract only", target: "drill rehearsed twice yearly",
      evidence: drills/gv-sc-10/last-run.log }

Then run the step the framework is built around. CSF 2.0's Step 4: "Conduct a gap analysis to identify and analyze the differences between the Current and Target Profiles, and develop a prioritized action plan (e.g., risk register, risk detail report, Plan of Action and Milestones [POA&M])". The gap analysis is the deliverable.

Click to zoom

Tiers: what CSF 2.0's own Tier language says about suppliers

CSF 2.0 defines four Tiers — "Partial (Tier 1), Risk Informed (Tier 2), Repeatable (Tier 3), and Adaptive (Tier 4)". Two things are routinely misreported.

First, there is no rubric. The Tier descriptions live in Appendix B under a table NIST titles a notional illustration — no percentage, no assessment method, no computed score. A tool reporting a Tier as a number invented that mechanism itself.

Second, the Function mapping is not body text. The sentence pairing "cybersecurity risk governance practices (GOVERN)" against "cybersecurity risk management practices (IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER)" appears in Appendix B's introductory paragraph on page 24, above the table. Sec. 3.2 says only "cybersecurity risk governance and management practices", naming no Function, and Fig. 4 is captioned the same way.

Supplier awareness sits at both ends of the ladder. Tier 1 describes an organisation "generally unaware of the cybersecurity risks associated with its suppliers and the products and services it acquires and uses"; Tier 4 uses "real-time or near real-time information" to act on them. The calibration question is whether anyone could say today which upstream project shipped a release into the cluster last week.

Four ways a self-hosted Profile goes wrong

1. Write-once. Filed after a questionnaire, never re-run. The estate moves underneath it and every row becomes a claim about a system that no longer exists. The fix is a cadence with a validator behind it.
2. Self-hosted read as supplier-free. Owning the metal does not remove suppliers, it decomposes one into many. A three-row GV.SC-04 register is not a good score, it is an incomplete inventory.
3. Upstream OSS excluded. The register lists things that send invoices. The kernel, the CNI, the storage layer and the runtime send none, and by NIST's own criteria they rank at the top. SBOM, Sigstore and SLSA on Kubernetes is how the transitive half stops being hand-maintained.
4. Evidence that cannot be regenerated. A console screenshot, a PDF export, a note that someone checked. If it cannot be produced again from the system itself, the row will not survive the second review.

GV.SC-10: from NIST's seven examples to a rehearsed exit drill

Be exact here, because it is easy to overclaim. NIST publishes seven Implementation Examples for GV.SC-10: processes "for terminating critical relationships under both normal and adverse circumstances" (Ex1), "component end-of-life maintenance support and obsolescence" (Ex2), prompt deactivation of supplier access (Ex3), verification "that assets containing the organization's data are returned or properly disposed of" (Ex4), and, over the page, a plan "for terminating or transitioning supplier relationships" (Ex5), mitigation of "risks to data and systems created by supplier termination" (Ex6), and management of "data leakage risks associated with supplier termination" (Ex7).

The gap is a delta, not a void. CSF 2.0 says the Examples "are not a comprehensive list of all actions that could be taken by an organization to achieve an outcome, nor do they represent a baseline of required actions". None names a container registry, a key custodian or a data export path — the things a self-hosted estate terminates against.

Two change meaning when you own the assets. Ex4's "assets containing the organization's data" is, self-hosted, your own storage cluster — so verification is not a certificate of destruction but a rehearsal that the data leaves in usable form. Ex5's transition plan, for a colocation exit, is a physical move with a registry mirror and a restore test in front of it.

#!/usr/bin/env bash
# gv-sc-10-drill.sh — rehearse termination for one contracted supplier.
# Illustrative scaffolding, not a product.
set -euo pipefail

SUPPLIER="${1:?usage: gv-sc-10-drill.sh <supplier-id>}"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
VAULT="/srv/exit-drill/$SUPPLIER/$STAMP"
MIRROR="registry.internal.example.net"
ISOLATED="restore-verify.internal.example.net"

mkdir -p "$VAULT"
exec > >(tee -a "$VAULT/drill.log") 2>&1

# Ex1 — can the estate run with the supplier's path unavailable?
# Running Pods only — a workload with no Pod today is missed.
kubectl get pods -A -o json \
  | jq -r '.items[].spec | (.initContainers // []) + .containers
           + (.ephemeralContainers // []) | .[].image' \
  | sort -u | tee "$VAULT/images.txt" \
  | while read -r img; do
      skopeo copy --all "docker://$img" "docker://$MIRROR/mirror/${img##*/}"
    done

# Ex4 — the assets holding the data are yours, so verification means
# proving the data leaves in restorable form.
etcdctl --endpoints=https://etcd-0.internal.example.net:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  snapshot save "$VAULT/etcd.db"
kubectl get secrets -A -o yaml \
  | age -R /etc/exit-drill/recipients.txt -o "$VAULT/secrets.yaml.age"
# Relative names only, and never the log still being written.
( cd "$VAULT" && sha256sum images.txt etcd.db secrets.yaml.age > SHA256SUMS )

# The step that turns an assertion into evidence: restore, do not just read.
rsync -a "$VAULT/" "$ISOLATED:/restore/$STAMP/"
ssh "$ISOLATED" "cd /restore/$STAMP && sha256sum -c SHA256SUMS \
  && etcdutl snapshot restore etcd.db --data-dir /tmp/restore-$STAMP \
  && etcdutl snapshot status etcd.db --write-out=table \
  && test -s /tmp/restore-$STAMP/member/snap/db"

Keeping the Profile honest: validation in CI

The failure mode a Profile in git fixes is staleness. Store it beside the infrastructure it describes and fail the build when a row goes missing, loses its evidence pointer, or points at a file that no longer exists. Profiles rarely go wrong dramatically; they go wrong by sitting still while the estate moves.

#!/usr/bin/env python3
"""validate_profile.py — fail the build when the GV.SC Profile goes stale."""
import datetime
import pathlib
import sys

import yaml

REQUIRED = [f"GV.SC-{n:02d}" for n in range(1, 11)]
REPO = pathlib.Path(__file__).resolve().parents[1]


def main(path: str) -> int:
    doc = yaml.safe_load(pathlib.Path(path).read_text(encoding="utf-8"))
    profile = doc["profile"]
    age = (datetime.date.today() - profile["reviewed"]).days
    rows = {row["id"]: row for row in doc["rows"]}
    errors = []

    if age > int(profile["cadence_days"]):
        errors.append(f"profile reviewed {age}d ago, cadence {profile['cadence_days']}d")
    for sub in REQUIRED:
        row = rows.get(sub)
        if row is None:
            errors.append(f"{sub}: missing from the Profile")
            continue
        for field in ("current", "target", "evidence"):
            if not row.get(field):
                errors.append(f"{sub}: no {field}")
        evidence = row.get("evidence")
        if evidence and not (REPO / evidence).exists():
            errors.append(f"{sub}: evidence does not resolve: {evidence}")

    for err in errors:
        print(f"FAIL {err}", file=sys.stderr)
    return 1 if errors else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "profile-gv-sc.yaml"))

Wire it into the pipeline that already lints the manifests. A governance artefact validated by CI cannot quietly rot. It does not monitor suppliers, though: GV.SC-07's evidence is the advisory-review log the Profile points at, and CI's job is failing the build when that pointer goes stale.

The long game: pin the reference, not just the practice

Frameworks move under you, quietly. Before version 2.0 this one was called "Framework for Improving Critical Infrastructure Cybersecurity", and CSF 2.0 states plainly that "This title is not used for CSF 2.0."

NIST's own guidance carries the same seam, live. SP 1305, dated October 2024, points readers to "NIST SP 800-161 Revision 1". NIST withdrew that designation on 1 November 2024 — one month later — superseding it with SP 800-161r1-upd1, an errata update whose changes are listed in Appendix K. That appendix records errata of both kinds, editorial and substantive, so this is not a claim the update was cosmetic. The point is narrower: a designation can be retired while guidance pointing at it stays published.

#!/usr/bin/env bash
# pin-references.sh — detect a silently updated source document.
set -euo pipefail
PINS="compliance/reference-pins.tsv"   # tab-separated: url, sha256
NIST="https://nvlpubs.nist.gov/nistpubs"
touch "$PINS"

DOCS=(
  "$NIST/CSWP/NIST.CSWP.29.pdf"
  "$NIST/SpecialPublications/NIST.SP.1301.pdf"
  "$NIST/SpecialPublications/NIST.SP.1305.pdf"
  "$NIST/SpecialPublications/NIST.SP.800-161r1-upd1.pdf"
)

rc=0
for url in "${DOCS[@]}"; do
  got="$(curl -fsSL "$url" | sha256sum | cut -d' ' -f1)"
  want="$(awk -v u="$url" -F'\t' '$1 == u { print $2 }' "$PINS")"
  if [ -z "$want" ]; then
    printf '%s\t%s\n' "$url" "$got" >> "$PINS"
  elif [ "$got" != "$want" ]; then
    echo "CHANGED $url  pinned=$want now=$got"; rc=1
  fi
done
exit "$rc"

That is the shape of the long game. Frameworks get renamed, renumbered and withdrawn on a cycle measured in years; the estate changes weekly. What survives both is a governance artefact held as text beside the systems it describes, pointing at evidence you can regenerate. CSF 2.0 will be superseded, and an honest register, a Profile pointing at git paths and a drill that has been run will map onto whatever replaces it.

Start narrow. Scope one Profile to the estate, fill GV.SC-04 so the upstream projects appear on it, point three rows at artefacts that already exist, and run the GV.SC-10 drill once against one contracted supplier. That produces a written answer to who you depend on — ranked, evidenced, with the ending planned while the relationship is healthy.