Third-Party Cyber Risk Playbook After DBIR 2025

A supplier questionnaire is not a security control. At most, it records what a provider was willing and able to declare on a particular day. A third-party risk program becomes operational when it connects business criticality, actual technical access, evidence that controls work, downstream dependencies, and the ability to disconnect or replace the supplier.

DBIR 2025 is a useful warning, but it should not become a decorative statistic attached to another annual survey. Verizon analyzed more than 22,000 incidents, including 12,195 confirmed breaches. Third parties were involved in 30% of breaches—twice the prior share—and ransomware appeared in 44%. The newer 2026 DBIR findings report supply-chain involvement in 48% of breaches. Keep the editions, observation periods, and denominators separate when presenting those figures.

Classify the relationship, not the supplier brand

Start with the function a provider supports. Determine whether an outage stops a critical process, what data crosses the boundary, whether the provider has administrative access, whether its code runs in a trusted environment, and how difficult it would be to substitute the service. A major SaaS company can be low impact in one workflow and critical in another. A single corporate-level rating obscures that difference.

The relationship register should connect the contract to services, integrations, data flows, technical identities, and both business and engineering owners. Add an impact tier and credible failure scenarios. This allows assurance effort to follow exposure: deep technical evidence and joint exercises go to relationships with a large blast radius, while low-impact services receive proportionate checks.

Reassess the tier when a provider gains a new permission, receives a more sensitive dataset, or becomes the sole route for a business function. Procurement category and annual spend are weak substitutes for operational dependency.

Replace declarations with scoped evidence

Define an evidence pack for high-impact providers. It may include a restore-test result, confirmation of enforced MFA, privileged-access design, logging coverage, vulnerability management performance, the outcome of the latest exercise, and the status of remediation actions. A certification or assurance report can contribute, but it does not answer every question about the service your organization actually consumes.

Each item needs scope, date, and ownership. A screenshot without an environment or a policy without a test result does not demonstrate effectiveness. NIST SP 800-161 Rev. 1 Update 1 treats cyber supply-chain risk as an enterprise-wide discipline, including flow-down requirements, supplier risk assessment, product and service integrity, and continuous integration with broader risk management.

Record exceptions explicitly. If a provider cannot produce an expected artifact, the outcome should be a compensating control, a remediation commitment, an accepted risk, or a decision not to proceed—not a silently completed checklist.

Govern supplier access as privileged access

Implementation accounts and remote support channels should not remain active for convenience. Bind access to an identified person, an approved task, and a limited time window. Use phishing-resistant MFA where feasible, network segmentation, session recording, individual accounts, and automatic expiry after the work period.

Measure how long it takes to revoke every form of supplier access, including API tokens, keys, local identities, support portals, and emergency accounts. A revocation drill gives stronger assurance than a process description. Monitor dormant accounts, credentials without owners, and connections that bypass the approved access path.

Service identities deserve the same attention as people. Document who can rotate a credential, where it is stored, which workloads depend on it, and what fails during revocation. Permanent broad tokens shared across environments turn a limited supplier incident into an internal compromise path.

Monitor integrations and material change

Risk often grows after onboarding. A provider adds integrations, expands its data scope, changes processing regions, or introduces a subcontractor. The assessment cannot end when the agreement is signed. A changed API schema, new OAuth scope, new outbound domain, or substantial increase in exported data should trigger review.

Combine supplier notifications with telemetry from your own side of the boundary. Useful signals include anomalous authentication, service-account use, synchronization failures, unexpected transfer patterns, and unsupported component versions. This does not require pretending to monitor every provider continuously. It means observing the technical interfaces that actually create exposure.

Set a cadence based on the relationship tier, but allow events to override it. A critical vulnerability, merger, control failure, processing-location change, or repeated SLA breach should initiate review before the calendar does.

Extend control to subcontractors

A critical service may depend on hosting, identity, payment processing, or support companies selected by the primary provider. Contracts should define when subcontractors may be added or changed, what notice is required, what information the customer receives, and when the customer can object or terminate.

A list of names is insufficient. Identify the function each subcontractor performs, the access it receives, and whether its failure creates concentration. NIS2 explicitly includes supply-chain security in cybersecurity risk-management measures, considering supplier-specific vulnerabilities and the quality of providers' security practices.

For the most important relationships, request evidence that requirements flow down. Otherwise, strong clauses with the primary supplier may stop at the first contractual boundary while sensitive processing continues further down the chain.

Design joint response and a workable exit

An incident annex should specify a continuously monitored channel, the minimum content of an initial notification, evidence-preservation duties, update cadence, and supplier participation in exercises. “Without undue delay” offers little operational value if nobody knows who answers the message or which facts are needed to assess impact.

The exit path deserves equal attention. Document export formats, credential revocation, deletion of retained copies, an alternative operating mode, and the owner of migration. For a critical service, rehearse at least integration isolation and degraded operation without the supplier. An exit plan that cannot be executed with available tools does not reduce concentration risk.

Coordinate communications and regulatory decisions without making the supplier the sole source of truth. Your organization needs enough independent logs and dependency knowledge to determine its own impact.

Report exposure reduction, not questionnaire volume

Boards do not need the number of assessments sent. More useful measures include the share of critical relationships with current integration maps, the percentage of privileged access that is time-bound, complete revocation time, restore-test coverage, unresolved subcontractor changes, and age of severe remediation findings.

Every threshold should lead to a decision: restrict access, require remediation, accept risk with accountable approval, or choose an alternative. The objective is not to label a supplier “secure.” It is to constrain plausible damage and demonstrate that the organization can continue or recover when a supplier control fails.

Sources

• Verizon: 2025 Data Breach Investigations Report
• Verizon: 2026 Data Breach Investigations Report — key findings
• NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices
• Directive (EU) 2022/2555 — NIS2