Editorial analysis and source review: 15 September 2026. The report was published in 2026 and uses data from 2025.
Two figures worth examining
Verizon released the 2026 DBIR on 19 May 2026. The Data Breach Investigations Report (DBIR) is an annual study in which Verizon, together with dozens of partner organisations, analyses thousands of real security incidents and confirmed breaches from the previous year. It has been published since 2008 and is one of the most frequently cited reports in the field. Its published summary states that 31% of analysed breaches started with exploitation of a software vulnerability. Breaches involving a third party accounted for 48% of all breaches in the DBIR data set. These figures describe the cases studied, not the probability of an attack on a particular company. They represent different views of incidents and should not be added together. Source: Verizon: DBIR 2026 announcement
For business leaders, these results offer a useful reason to examine existing assumptions. They do not determine which project should receive funding first. A budget must account for specific services, dependencies, existing controls and the consequences of disruption. The same statistic may support different decisions in a manufacturing plant and a small consultancy.
Our analysis: apply the findings to your environment
The following approach is our practical interpretation, rather than another finding from the DBIR. Start with one business process: accepting an order, dispatching goods or paying salaries. Identify its owner and the systems required to complete it. Then ask which weakness could interrupt that process and what evidence you have that the risk is being managed.
For vulnerabilities, we recommend examining internet exposure, data sensitivity, process privileges and the ability to apply updates safely. A scanner's total finding count does not provide this context. Establish who approves remediation, who performs it and who verifies that the original exposure has actually been removed.
For suppliers, ask what access your company has granted. A contract, a cloud application and a support account create different dependencies. Record the owner, permission scope, incident contact and disconnection procedure for each critical integration. Testing access removal may reveal a problem that a supplier questionnaire would not expose.
Comparing two investments
Consider a hypothetical company choosing between another security dashboard and regular maintenance of an internet-facing application. This is an illustrative scenario, not a case from the report. Both proposals should explain which risk they address and how the change would affect normal operations.
Maintenance requires an owner, testing capacity, agreed downtime and a rollback procedure. A dashboard requires someone to assess alerts who also has authority to act. Include staff effort and dependencies on other departments in the comparison. A cheaper licence does not necessarily deliver a simpler or more effective control.
We suggest attaching a short decision record to each investment: the service being protected, a specific scenario, the proposed change, an accountable person, required capacity and a verification method. Management can then compare the outcomes the business needs and explicitly recognise the risk of a deferred project. Record uncertainties too: which dependencies are still unknown and what measurement would help resolve them.
What to bring to the next management meeting
Choose the most important service and prepare a single overview connecting its technical condition with business operations:
- Which unresolved weaknesses threaten its availability or data?
- Which suppliers and accounts can affect how it operates?
- Who authorises remediation, access restrictions or downtime?
- What result from the next test would demonstrate improvement?
Agree when the decision will be reviewed and retain evidence from completed checks. Supplement an “addressed” status with the scope and outcome of verification, so another person can understand what was actually checked. If an assumption proves wrong, update both the priority and the approach. This turns the security budget discussion into a set of concrete decisions and responsibilities. The DBIR supplies external context; verification within your organisation shows what your business needs.