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.
SP 800-161 is tailorable C-SCRM guidance; DORA is binding EU law for financial entities in scope. Map overlapping evidence without treating NIST adoption as DORA conformity.
Use NIST SP 800-161 Rev. 1 to build the cybersecurity supply chain risk management (C-SCRM) program; use to determine the legal duties of an in-scope EU financial entity. NIST Rev. 1 was published in May 2022 and Update 1 includes changes through 1 November 2024; DORA has applied since 17 January 2025. NIST records can support DORA work, but they do not establish DORA compliance unless they prove the specific DORA duty, scope, owner, contract term, register entry, or deadline.
Side-by-side comparison
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 ICT third-party risk with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.
NIST SP 800-161 Rev. 1 is tailorable C-SCRM guidance. It supplies a multilevel program model, practices, controls, and templates, but it does not itself create -style legal scope, deadlines, supervision, or penalties.
Second framework
DORA ICT third-party risk
is a binding EU regulation for financial entities in scope. Its ICT third-party risk duties, contractual requirements, register of information, incident regime, resilience framework, and critical-provider oversight must be analyzed on DORA's own terms.
NIST SP 800-161 Rev. 1 vs DORA ICT third-party risk: practical side-by-side comparison
SP 800-161 gives C-SCRM practices that can support supplier risk governance. Use NIST SP 800-161 Rev. 1 to define the in-scope system, product, service, supplier, release, incident, or governance process before mapping evidence.
applies to the financial entities listed in Article 2, subject to stated exclusions and proportionality provisions. Its ICT third-party chapter covers contractual arrangements for ICT services; additional analysis is required when the service supports a critical or important function.
SP 800-161 assigns C-SCRM responsibilities across enterprise, mission or business-process, and operational levels. Senior leaders, risk owners, system owners, acquisition staff, security teams, and supplier managers contribute according to the decision.
Under , the financial entity remains responsible for compliance when it uses an ICT third-party provider. Its management body defines and approves the ICT risk framework, while legal, procurement, security, service owners, and control functions execute and evidence the arrangement.
Name the -accountable financial entity and management-body governance separately from the people who operate the NIST C-SCRM process or supply evidence.
SP 800-161 has no universal legal applicability trigger. Adopt it when federal requirements, contracts, customers, internal policy, or voluntary risk-management objectives call for C-SCRM; reassess after material mission, system, supplier, product, threat, vulnerability, or incident changes.
duties begin with an in-scope financial entity using an ICT service. Support for a critical or important function changes due diligence, contract, concentration-risk, exit, and notification considerations. Critical-provider designation is a separate oversight trigger.
NIST SP 800-161 Rev. 1 organizes supplier risk work into a practical program: identify and assess supply chain risks, select controls and mitigations, maintain trusted relationships and records, and keep the process under governance review.
requires the financial entity to manage ICT risk, keep a register of ICT contractual arrangements, assess risk before contracting, address concentration and exit risk, include the applicable Article 30 provisions in written contracts, classify and report major ICT-related incidents, and test digital operational resilience.
SP 800-161 evidence can include strategy and policy, C-SCRM plans and risk assessments, criticality and supplier inventories, selected controls, acquisition records, contract clauses, assessment and test results, monitoring, incidents, response decisions, metrics, and plans of action.
evidence includes the register of information, pre-contract assessment, approval record, written agreement and Article 30 clauses, service and security monitoring, audit and access evidence, incident cooperation, concentration-risk analysis, tested exit planning, and records supplied to competent authorities where required.
For each claim, record the article, entity, arrangement, supported function, owner, artifact, review date, and NIST record reused. Label partial support and missing legal fields.
SP 800-161 does not set a universal application date, incident clock, remediation window, or certification renewal. Define risk-based periodic and event-driven reviews, plus any timing imposed by the federal, contractual, customer, or policy instrument adopting it.
has applied since 17 January 2025 and uses legally defined timing for matters such as major ICT-related incident reporting. Track the regulation and applicable technical standards separately from internal C-SCRM cadence.
A risk-based SP 800-161 monitoring schedule cannot replace a legal clock. Keep the source, trigger, owner, due time, and evidence for each timer distinct.
NIST does not certify or enforce SP 800-161. Assurance comes from the adopting context, such as federal oversight, system authorization, a contract or customer review, internal audit, control assessment, or enterprise risk governance.
is supervised and enforced through the competent-authority and European supervisory framework, including oversight of designated critical ICT third-party providers and penalties implemented under the regulation and national law.
Use SP 800-161 to strengthen the operating C-SCRM capability, but use 's text and technical standards to determine legal accountability, evidence, reporting, supervision, and enforcement exposure.
can reuse those records when they cover the same legal entity, ICT service, provider, function, risk, contract, and period. DORA-specific register fields, clauses, classifications, notices, and deadlines still need direct evidence.
Use SP 800-161 as the operating model for enterprise C-SCRM, supplier and product risk, acquisition, tailored controls, monitoring, and risk response across IT and operational technology supply chains.
Use as the controlling legal source when an in-scope financial entity manages ICT risk and ICT third-party arrangements, including services supporting critical or important functions.
Keep NIST as the program layer and as the legal requirements layer. Approve the mapping only after every DORA duty has direct, partial, or missing evidence recorded.
SP 800-161 gives C-SCRM practices that can support supplier risk governance. Use NIST SP 800-161 Rev. 1 to define the in-scope system, product, service, supplier, release, incident, or governance process before mapping evidence.
applies to the financial entities listed in Article 2, subject to stated exclusions and proportionality provisions. Its ICT third-party chapter covers contractual arrangements for ICT services; additional analysis is required when the service supports a critical or important function.
SP 800-161 assigns C-SCRM responsibilities across enterprise, mission or business-process, and operational levels. Senior leaders, risk owners, system owners, acquisition staff, security teams, and supplier managers contribute according to the decision.
Under , the financial entity remains responsible for compliance when it uses an ICT third-party provider. Its management body defines and approves the ICT risk framework, while legal, procurement, security, service owners, and control functions execute and evidence the arrangement.
Name the -accountable financial entity and management-body governance separately from the people who operate the NIST C-SCRM process or supply evidence.
SP 800-161 has no universal legal applicability trigger. Adopt it when federal requirements, contracts, customers, internal policy, or voluntary risk-management objectives call for C-SCRM; reassess after material mission, system, supplier, product, threat, vulnerability, or incident changes.
duties begin with an in-scope financial entity using an ICT service. Support for a critical or important function changes due diligence, contract, concentration-risk, exit, and notification considerations. Critical-provider designation is a separate oversight trigger.
NIST SP 800-161 Rev. 1 organizes supplier risk work into a practical program: identify and assess supply chain risks, select controls and mitigations, maintain trusted relationships and records, and keep the process under governance review.
requires the financial entity to manage ICT risk, keep a register of ICT contractual arrangements, assess risk before contracting, address concentration and exit risk, include the applicable Article 30 provisions in written contracts, classify and report major ICT-related incidents, and test digital operational resilience.
SP 800-161 evidence can include strategy and policy, C-SCRM plans and risk assessments, criticality and supplier inventories, selected controls, acquisition records, contract clauses, assessment and test results, monitoring, incidents, response decisions, metrics, and plans of action.
evidence includes the register of information, pre-contract assessment, approval record, written agreement and Article 30 clauses, service and security monitoring, audit and access evidence, incident cooperation, concentration-risk analysis, tested exit planning, and records supplied to competent authorities where required.
For each claim, record the article, entity, arrangement, supported function, owner, artifact, review date, and NIST record reused. Label partial support and missing legal fields.
SP 800-161 does not set a universal application date, incident clock, remediation window, or certification renewal. Define risk-based periodic and event-driven reviews, plus any timing imposed by the federal, contractual, customer, or policy instrument adopting it.
has applied since 17 January 2025 and uses legally defined timing for matters such as major ICT-related incident reporting. Track the regulation and applicable technical standards separately from internal C-SCRM cadence.
A risk-based SP 800-161 monitoring schedule cannot replace a legal clock. Keep the source, trigger, owner, due time, and evidence for each timer distinct.
NIST does not certify or enforce SP 800-161. Assurance comes from the adopting context, such as federal oversight, system authorization, a contract or customer review, internal audit, control assessment, or enterprise risk governance.
is supervised and enforced through the competent-authority and European supervisory framework, including oversight of designated critical ICT third-party providers and penalties implemented under the regulation and national law.
Use SP 800-161 to strengthen the operating C-SCRM capability, but use 's text and technical standards to determine legal accountability, evidence, reporting, supervision, and enforcement exposure.
can reuse those records when they cover the same legal entity, ICT service, provider, function, risk, contract, and period. DORA-specific register fields, clauses, classifications, notices, and deadlines still need direct evidence.
Use SP 800-161 as the operating model for enterprise C-SCRM, supplier and product risk, acquisition, tailored controls, monitoring, and risk response across IT and operational technology supply chains.
Use as the controlling legal source when an in-scope financial entity manages ICT risk and ICT third-party arrangements, including services supporting critical or important functions.
Keep NIST as the program layer and as the legal requirements layer. Approve the mapping only after every DORA duty has direct, partial, or missing evidence recorded.
When should teams use NIST SP 800-161 Rev. 1 first versus DORA ICT third-party risk first?
Use NIST SP 800-161 Rev. 1 first to design or improve the C-SCRM program, supplier risk process, acquisition controls, monitoring, and response.
Use first to decide legal scope, governance, register content, due diligence, contract terms, reporting clocks, testing, exit planning, and supervisory evidence.
Use both when the same supplier or ICT service falls inside the C-SCRM program and a -regulated arrangement. Record the remaining DORA-only requirements.
Start with when the organization is a financial entity within Article 2 and the work concerns information and communication technology (ICT) services, especially services supporting a critical or important function. DORA uses that category when disrupted performance would materially impair financial performance, the soundness or continuity of services and activities, or continued compliance with authorization conditions or other financial-services law. Articles 28 to 30 govern ICT third-party risk, the register of information, pre-contract risk assessment, concentration risk, exit strategies, and contractual provisions.
Article 2 covers categories such as credit and payment institutions, investment firms, crypto-asset service providers, insurers, pension institutions, critical benchmark administrators, crowdfunding service providers, and other listed financial entities. Article 2(3) excludes specified small or exempt entities, including institutions for occupational retirement provision that operate pension schemes which together have no more than 15 members in total; Article 16 gives certain other entities a simplified ICT risk-management framework rather than a blanket exemption. Confirm the entity's authorization and Member State treatment instead of deciding scope from its trading name or size alone.
Start with SP 800-161 when the decision is how to organize C-SCRM across enterprise, mission or business-process, and operational levels. Rev. 1 Update 1 includes updates through November 2024 and covers strategy, policy, plans, risk assessments, acquisition, controls, supplier information, monitoring, and response.
When both apply, map each requirement to the NIST practice and artifact that supports it. Mark a gap when the NIST record lacks DORA-specific content, such as complete register data, a required contract clause, an exit plan for a critical or important function, or a statutory reporting clock.
Legal and compliance: confirm the entity category, competent authority, ICT service, and whether a critical or important function is supported.
Security and enterprise risk: define the NIST risk-management level, system boundary, supplier, product or service, threats, controls, risk response, and monitoring evidence.
Procurement and service owners: connect due diligence, approval, contract clauses, subcontracting conditions, service levels, audit and access rights, incident cooperation, termination rights, and exit evidence to the applicable source.
Critical ICT third-party provider designation creates a separate EU oversight layer; it is not the test for whether a financial entity must manage an ICT provider.