Updated September 2026NIST SP 1326 informed

Do enough supplier due diligence to make the risk visible before the contract makes it expensive.

Third-party cyber risk is not solved by sending every vendor the same 200-question spreadsheet. This guide uses NIST’s finalized 2026 due-diligence model to build a proportional public-sector process for supplier research, evidence review, contracting, ongoing monitoring, incident coordination, and exit.

Risk tiering

Start with what the supplier can affect.

Supplier criticality should come from the service relationship, not company size. A small specialty vendor with privileged access to a case-management environment may create more operational and confidentiality risk than a much larger vendor providing a noncritical public information service.

Capture the data handled, identities and privileges, production access, integration depth, service criticality, recovery dependency, geographic or legal exposure, replaceability, concentration risk, and whether the supplier can introduce software or changes into the environment. Use that profile to decide how much diligence is justified.

Low dependency

No sensitive data, no privileged access, limited integration, and an easy substitute. Use baseline checks and standard terms.

Material dependency

Sensitive information, important workflows, integrations, administrative access, or meaningful outage impact. Require deeper evidence and lifecycle monitoring.

Critical dependency

Mission-essential service, concentrated access, difficult recovery, safety implications, or high switching cost. Treat continuity, incident cooperation, and exit as core requirements.

NIST 2026 due diligence

Investigate five supplier dimensions before relying on self-attestation.

NIST SP 1326, finalized July 8, 2026, organizes ICT supplier due diligence around Foreign Ownership, Control, or Influence; provenance; resilience; foundational cyber practices; and supply-chain tiers.

Ownership and influence

Understand who owns or controls the organization, relevant parent/subsidiary relationships, operating jurisdictions, and whether those relationships create legal, operational, national-security, procurement, or continuity concerns.

Provenance

Know where the supplier and material product components originate, how the service is developed or assembled, and which facts are verified versus assumed.

Resilience

Assess whether the supplier can sustain operations through outages, cyber incidents, financial distress, upstream disruption, staffing loss, regional failure, or dependency failure.

Foundational cyber practices

Look for observable evidence of identity security, vulnerability management, secure development, logging, incident response, asset management, customer security controls, and public-facing hygiene.

Supply-chain tiers

Identify critical subprocessors, hosting providers, component suppliers, libraries, support dependencies, and other tiers that can materially affect the buyer even when they are not direct contractors.

Decision traceability

Record the sources reviewed, findings, uncertainty, material exceptions, reviewer, date, and resulting procurement decision so diligence is reproducible later.

Evidence hierarchy

Ask for proof that matches the risk you are trying to understand.

Certifications can be useful evidence, but they should not become a universal substitute for technical and operational facts. A SOC report may support control assurance while still leaving unanswered questions about the exact hosted service, privileged support access, incident notification, customer log visibility, subcontractors, data deletion, or recovery.

Useful evidence

  • Current independent assessments or certifications with scope visible.
  • Architecture and data-flow documentation.
  • Identity, administrative-access, and logging design.
  • Vulnerability-management and secure-development practices.
  • Penetration-test or assessment summaries appropriate to the relationship.
  • Incident-response and customer-notification process.
  • Backup, recovery, continuity, and resilience evidence.
  • Subprocessor and material dependency information.

Evidence quality checks

  • Is it current enough for the decision?
  • Does it cover the exact service or environment being purchased?
  • Who produced it and what independence did they have?
  • Are important exclusions or exceptions visible?
  • Can the buyer retain it for future comparison?
  • Does the supplier update it after material change?
  • Does it answer the requirement, or merely signal maturity?
Risk decision

Turn findings into explicit acceptance, mitigation, or rejection.

Do not reduce supplier risk to a single questionnaire percentage. Classify findings by the decision they require. A missing policy document may be low impact; an inability to export authoritative records, support MFA for administrators, provide incident evidence, or recover a mission-critical service may be disqualifying.

  • Accept: evidence is sufficient and the residual risk fits the organization’s tolerance.
  • Mitigate before award: the supplier must change configuration, provide evidence, narrow scope, add a contractual control, or satisfy an acceptance test.
  • Accept temporarily: a named authority accepts a time-bounded exception with compensating controls, owner, due date, and re-review trigger.
  • Reject: the supplier cannot meet a mandatory requirement or the residual risk is inconsistent with the mission.

Use the Software Evaluation Scorecard to keep mandatory failures outside the weighted average so a strong feature demo cannot numerically cancel a critical security or continuity gap.

Contract controls

Carry material findings into enforceable operating terms.

  • Security and privacy requirements tied to the service.
  • Material-change notification.
  • Incident notification and cooperation.
  • Evidence preservation and access.
  • Subprocessor and hosting changes.
  • Vulnerability remediation expectations.
  • Data return, deletion, and portability.
  • Recovery, continuity, and transition assistance.
Secure by demand

Make secure behavior part of what the customer buys.

CISA’s Secure by Demand guidance emphasizes that software customers can influence manufacturers by explicitly requesting security outcomes during procurement. Translate that idea into concrete acceptance criteria instead of generic language such as “industry standard security.”

Examples include phishing-resistant MFA for administrators, security logging available to the customer, secure defaults, vulnerability disclosure, timely security updates, and documented support lifecycles where applicable.

Lifecycle monitoring

Reassess on meaningful change, not only on an annual calendar.

Annual review may still be useful, but risk changes when the relationship changes. Reassess after major acquisitions, new subprocessors, hosting-region changes, significant incidents, security-control changes, new privileged access, major product redesign, material contract changes, service degradation, financial instability, or expansion into higher-risk data and workflows.

Maintain a compact supplier record: service owner, criticality, data handled, privileged access, dependencies, last diligence date, open findings, accepted exceptions, incidents, contract controls, recovery dependency, exit method, and next trigger. That record makes vendor risk usable during operations instead of trapping it in a procurement folder.

Operational governance

Make the vendor-risk record usable during incidents, renewals, audits, and budget decisions.

A due-diligence package has limited value if it disappears after contract award. The organization should be able to answer, quickly and from one maintained record, what the supplier does, which systems and data depend on it, who owns the relationship, what access it holds, which upstream providers matter, what unresolved risks were accepted, and what evidence supported the last decision. This turns vendor risk from a procurement exercise into an operational control.

Separate facts from judgments. Record verifiable service attributes and evidence sources independently from the resulting risk rating or acceptance decision. When a supplier changes hosting, support access, subprocessors, ownership, product architecture, or recovery commitments, reviewers can then identify exactly which prior assumptions are no longer valid instead of repeating the entire assessment or, worse, assuming the previous result still applies.

Define evidence freshness by consequence. A critical identity provider or case-management platform may justify current recovery evidence, recent independent assurance, verified incident contacts, and frequent review of material dependencies. A low-impact commodity service may only require confirmation that scope and access have not materially changed. Proportional review reduces paperwork while concentrating effort where stale evidence would create the greatest operational uncertainty.

Use the record at renewal time as a decision brief, not a filing cabinet. Summarize open findings, incidents, service performance, material changes, accepted exceptions, cost or concentration concerns, continuity tests, and exit readiness. Renewal should confirm that the original reasons for accepting the dependency still hold and that new risks are either mitigated, explicitly accepted, or strong enough to justify replacement planning.

Minimum maintained fields

Service owner, business purpose, data classes, privileged access, integrations, critical dependencies, hosting and subprocessors, recovery expectations, incident contacts, open findings, exception expirations, contract protections, and next review trigger.

Useful event triggers

Security incident, acquisition, major outage, control failure, new privileged access, major architecture change, material subprocessor change, scope expansion, repeated SLA failure, significant price or contract change, or an approaching renewal or termination window.

Exit readiness

A supplier is not truly replaceable until the organization can recover its data, configuration, knowledge, and workflow.

Test export format, completeness, relationships, attachments, metadata, audit history, identity transition, integration replacement, documentation, and deletion evidence before the dependency becomes urgent. A CSV export does not necessarily reproduce the operational system.

For critical suppliers, define the conditions that trigger an exit assessment and who owns it. Insolvency, repeated security failure, unacceptable service degradation, strategic acquisition, loss of required certification, severe incident, or material pricing/contract change may all justify a fresh continuity decision.

Continue with the Software Continuity & Exit Readiness checklist for a detailed operational exit review.

Continue learning

Related guides after Public-Sector Third-Party Cyber Risk

Follow the next implementation topic without returning to search.

Put this guide to work

Turn Public-Sector Third-Party Cyber Risk Guide | Zeph Tech into a decision-ready next step.

Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.