We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALNIST SP 800-161 Rev. 1

NIST SP 800-161 Rev. 1 Criticality Analysis Guide

Identify mission-critical functions and trace them through systems, components, products, services, suppliers, sub-tiers, and single-source dependencies.

Criticality identifies what is vital; it does not by itself determine likelihood, overall risk, or a fixed supplier tier. Combine it with threat, vulnerability, impact, dependency, and available alternatives.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
2

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

identifies the mission and business processes that must keep working, then traces the systems, functions, components, products, services, infrastructure, and suppliers that support them. Use the result to prioritize deeper assessment and protection. Criticality describes consequence and dependency; a risk assessment must still consider threats, vulnerabilities, likelihood, existing controls, and available responses.

Section 1

What criticality analysis helps a team decide

starts with mission and business functions, then identifies the systems and functions that enable them and the components, products, services, suppliers, and supply paths on which those systems depend. NIST does not prescribe a universal score, threshold, or fixed list of critical suppliers. The enterprise defines documented criteria that fit the decision and its risk context; supplier spend or a questionnaire score alone does not establish criticality.

NIST describes both top-down and bottom-up analysis. Top-down analysis starts with critical processes and traces them to supporting systems, functions, and components. Bottom-up analysis starts with a compromised, unavailable, or malfunctioning component and traces the effect upward to the system and mission. Use both views to expose common dependencies, single points of failure, and . For example, two otherwise unrelated prime suppliers may depend on the same cloud, network, component, or logistics provider, creating one shared point of failure.

  • Define impact in operational terms: unacceptable outage or degradation, loss of confidentiality or integrity, safety effect, recovery need, or failure of a required mission outcome.
  • Record why each dependency is critical, the evidence and assumptions behind that decision, and the owner authorized to approve the resulting priority.
  • Use criticality to set assurance depth, control tailoring, provenance and authenticity checks, contract requirements, monitoring, contingency planning, and response priority.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix G explains critical processes, top-down and bottom-up analysis, critical supplier dependencies, analysis across all three levels, and iterative review during Frame, Assess, and Monitor.
NIST IR 8179 Criticality Analysis Process Model
NIST's process model for identifying and prioritizing vital systems and components and tracing their relationship to mission and business processes.
Section 2

Set the boundary and run both directions

Choose a decision boundary before scoring anything: an enterprise objective, mission or business process, system, service, product, acquisition, or planned architecture. Record the operating environment, required outcome, time horizon, rating method, and what is outside scope. A result for one system or mission should not be reused for another without checking whether impact, access, dependency, and replacement options are still the same.

Run a top-down trace from the required outcome to dependencies, then challenge it bottom-up with plausible component, service, or supplier failures. Include shared infrastructure and sub-tier dependencies that may support several systems. Missing visibility is an uncertainty to manage, not evidence that the dependency is unimportant.

  • Top-down: mission or business process -> supporting system -> critical function -> component or service -> supplier and supply path.
  • Bottom-up: component, service, or supplier failure -> affected system function -> operational impact -> mission or business consequence.
  • Cross-check: common fourth parties, cloud or network dependencies, build and maintenance services, facilities, people, power, and other unmediated support.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix G describes top-down and bottom-up criticality analysis and directs enterprises to include system and cybersecurity supply-chain dependencies, including critical fourth-party suppliers.
NIST IR 8179 Criticality Analysis Process Model
Primary NIST reference for the criticality-analysis process model cited by SP 800-161.
Section 3

Evidence and ownership checklist

A defensible analysis preserves the path from mission or business function to enabling system, critical function, component, product or service, supplier and sub-tier dependency, potential failure mode, impact, and treatment. Record uncertainty and missing visibility rather than forcing false precision.

Assign mission and business owners to validate impact, system and engineering owners to validate dependencies, acquisition and supplier-risk owners to validate sources and alternatives, and the authorized risk owner to approve priorities and residual risk.

  • Mission or business function, required outcome, acceptable outage or degradation, and confidentiality, integrity, safety, recovery, customer, or partner impacts.
  • Dependency map covering systems, critical functions, components, products, services, suppliers, sub-tiers, facilities, and single points of failure.
  • Criticality criteria, scale or decision rule, evidence, assumptions, uncertainty, rating rationale, alternatives, owner, approval, and link to the resulting assurance treatment.
  • Review triggers for architecture, supplier, ownership, location, sourcing, component, threat, vulnerability, incident, end-of-life, or mission changes.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix G calls for documented procedures and iterative enterprise-, mission-, operational-, system-, subsystem-, and component-level analysis.
NIST IR 8179 Criticality Analysis Process Model
Supports a repeatable record linking mission and business processes to systems and components.
Recommended next step

Run a criticality analysis

Trace mission and business needs through systems, components, services, suppliers, and sub-tiers, then assign the resulting assurance treatment.

Assessment workflow
Open Assessment Autopilot

Assign dependency mapping, evidence collection, review, and treatment decisions.

Explore next step
Talk to Sorena
Review the criticality model

Check boundaries, dependency traces, assumptions, owners, and treatment gaps.

Explore next step
Section 4

Common mistakes that weaken the analysis

A supplier can be critical even when spend is low, and a well-known supplier is not automatically low risk. Conversely, rating every supplier as critical prevents prioritization. Analyze the function and dependency before applying the label.

Do not stop at the prime supplier. A deeply embedded component, cloud dependency, maintainer, build service, or sole-source sub-tier may create the decisive exposure.

  • Do not equate criticality with current threat likelihood; criticality primarily describes consequence and dependency, while the risk assessment adds threat, vulnerability, likelihood, and existing controls.
  • Do not use a single enterprise score when the same supplier supports systems with materially different impact and replacement options.
  • Do not collect ratings without tying them to deeper assessment, contract, testing, provenance, monitoring, incident, and continuity treatment.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix G separates criticality from the later threat, vulnerability, likelihood, impact, and risk-response analysis and warns that supply-chain interdependencies can extend beyond the prime supplier.
Section 5

Practical workflow for criticality analysis

Run an initial during risk framing, add detail during assessment, and revisit it when monitoring identifies a change that could alter the result. NIST does not set a calendar deadline; the enterprise should define review intervals and event triggers. Start with what the enterprise must accomplish, not with the vendor list.

The output is a prioritized dependency view and treatment decision that can be consumed by risk assessment, acquisition, engineering, supplier assurance, incident response, and continuity teams.

  • 1 | Mission scope | Identify the mission or business function, required outcomes, and impact if it is compromised or unavailable.
  • 2 | Dependency trace | Map enabling systems and functions to components, products, services, suppliers, sub-tiers, and supply paths.
  • 3 | Criticality decision | Use top-down and bottom-up traces to evaluate consequence, concentration, access, substitutability, recovery time, life-cycle stage, and uncertainty.
  • 4 | Treatment | Set assessment depth, controls, contract terms, testing, provenance, monitoring, response, and contingency expectations.
  • 5 | Feedback | Approve the result and refresh it after material mission, architecture, supplier, threat, vulnerability, incident, or sourcing change.
Sources for this answer
NIST SP 800-161 Rev. 1 Update 1 C-SCRM
Appendix G places criticality analysis in the Frame and Assess steps and calls for iteration when the Monitor step identifies a change.
NIST IR 8179 Criticality Analysis Process Model
Provides the underlying NIST process model for prioritizing systems and components.
Primary sources

References and citations

NIST SP 800-161 Rev. 1 Update 1 C-SCRM
doi.org
Referenced sections
  • Appendix G places criticality analysis in the Frame and Assess steps and calls for iteration when the Monitor step identifies a change.
Related guides

Explore more topics

How should teams handle counterfeits under NIST SP 800-161 Rev. 1 supply-chain risk management?
Prioritize critical items, use traceable sources, verify authenticity and tamper protection, quarantine suspected counterfeits, and reassess affected risk.
How should teams handle critical suppliers under NIST SP 800-161 Rev. 1 supply-chain risk management?
Identify critical suppliers through mission dependency, component importance, access, concentration, substitutability, and potential impact, not spend alone.
How should teams handle monitoring under NIST SP 800-161 Rev. 1 supply-chain risk management?
Run risk-based supplier monitoring with scheduled revalidation, event triggers, operating signals, escalation thresholds, corrective action, and evidence.
How should teams handle provenance under NIST SP 800-161 Rev. 1 supply-chain risk management?
Collect and verify traceable origin, build, dependency, custody, authenticity, and change evidence for critical systems, components, software, and data.
How should teams handle supplier incidents under NIST SP 800-161 Rev. 1 supply-chain risk management?
Coordinate supplier incidents through joint triage, evidence preservation, containment, recovery, contract communication, corrective action, and reassessment.
How should teams handle supply chain risk response under NIST SP 800-161 Rev. 1 supply-chain risk management?
Choose and document whether to accept, avoid, mitigate, share, or transfer supply-chain risk, with authority, actions, residual risk, and review triggers.
How should teams handle tiering under NIST SP 800-161 Rev. 1 supply-chain risk management?
Build supplier risk categories that drive assurance treatment while keeping them distinct from SP 800-161 risk-management levels and CSF Tiers.
NIST SP 800-161 Rev. 1 C-SCRM Governance Checklist
A NIST SP 800-161 Rev. 1 checklist for assigning C-SCRM decisions across enterprise, mission/business-process, and operational levels.
NIST SP 800-161 Rev. 1 C-SCRM Governance Guide
Design NIST SP 800-161 Rev. 1 C-SCRM governance across the enterprise, mission/business-process, and operational levels with accountable roles and feedback loops.
NIST SP 800-161 Rev. 1 Contract and Monitoring Controls
Translate C-SCRM risk decisions into supplier clauses, subcontractor flow-down, evidence delivery, revalidation, monitoring, incident, continuity, and exit terms.
NIST SP 800-161 Rev. 1 FAQ: practical implementation questions
NIST SP 800-161 Rev. 1 answers with cited implementation steps, decision criteria, and evidence guidance.
NIST SP 800-161 Rev. 1 implementation playbook
Build a tailored C-SCRM program with strategy, policy, plans, assessments, acquisition controls, monitoring, and evidence across NIST's three risk-management levels.
NIST SP 800-161 Rev. 1 Provenance and SBOM Supplier Controls
Use provenance, SBOM, build integrity, authenticity, and supplier evidence together to manage software and component risk under NIST SP 800-161 Rev. 1.
NIST SP 800-161 Rev. 1 supplier assessment evidence: risk-based records and evaluation criteria
Choose and validate supplier evidence based on criticality, risk, contract requirements, source reliability, freshness, and proof of operating effectiveness.
NIST SP 800-161 Rev. 1 Supplier Risk Tiering
Group suppliers by mission dependency and cyber risk, then tie each category to proportionate due diligence, evidence, contracts, monitoring, and response.
NIST SP 800-161 Rev. 1 vs DORA ICT third-party risk: practical side-by-side comparison
Compare NIST SP 800-161 Rev. 1 and DORA ICT third-party risk with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.
NIST SP 800-161 Rev. 1 vs ISO/IEC 27036 supplier relationships: practical side-by-side comparison
Compare NIST SP 800-161 Rev. 1 and ISO/IEC 27036 supplier relationships with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.
NIST SP 800-161 Rev. 1: workflow for collecting and validating C-SCRM supplier evidence
A risk-based NIST SP 800-161 supplier evidence workflow from relationship scope and criticality through request, validation, decision, remediation, and monitoring.
Which contract controls should teams define under NIST SP 800-161 Rev. 1?
Translate supplier risk into measurable security, flow-down, evidence, monitoring, incident, continuity, remediation, and exit clauses under SP 800-161.