Low dependency
No sensitive data, no privileged access, limited integration, and an easy substitute. Use baseline checks and standard terms.
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.
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.
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.
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.
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.
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.