Hey everyone! It has been crazy here at Senserva, the release of Siemserva has been keeping us very busy. But this we HAVE to talk about. The 2026 Verizon Data Breach Investigations Report dropped last month, and if you spend any time in compliance or security assurance work - on either side of the clipboard - there are some numbers in here that should change how you think about what a security assessment actually proves. And how we can help.
This year there's a new dimension: AI. The attackers are using it. The DBIR has the data to prove it. And the gap between organizations with reliable AI-powered security tools and those just hoping their policies are still accurate is getting wider fast.
Let's go through the numbers that matter most.
A few stats to anchor the conversation:
Those are not abstract statistics. They are a profile of the organization most likely to show up in next year's breach list. And to make matter worse, there is now an AI layer accelerating all of it.
This is the part of the 2026 DBIR that most compliance summaries will underplay, so let's not.
Verizon partnered with Anthropic - the company that builds Claude - to analyze how threat actors are actually using AI platforms against targets. They tracked 793 unique threat actors who had enforcement action taken against them for violating acceptable use policies while using AI for malicious cybersecurity activity.
In the median case, a threat actor was using AI assistance across 15 distinct ATT&CK techniques in a single campaign. In extreme cases, actors were querying across 40 or 50 techniques - treating AI as a co-developer across the full attack chain, from initial research through exploitation and cleanup.
AI-assisted phishing text doubled compared to prior years. And while the DBIR found that AI isn't yet unlocking fundamentally new attack techniques, it is doing something arguably more dangerous: it is scaling and accelerating techniques defenders already know how to detect - but can't keep up with manually. Read that again. The report's framing is precise: AI's current impact on attacks is primarily operational. It makes existing attacks faster, more adaptive, and more accessible to lower-skilled actors.
The DBIR's own conclusion: "The baseline of what can be achieved with relative low cost is broader... any industrialization, even of simple techniques, could make the gap between the cybersecurity haves and have-nots even wider."
For a compliance audience, this matters in a very specific way. A control that was adequate last year, assessed on a point-in-time basis, may already be under a different category of pressure. The pace of attack is accelerating. The pace of most compliance review cycles is not.
Here's the challange; its knowing what your compliance reviews actually measure. Often, they measure whether you have documentation that is in order. Whether your policies exist. Whether someone signed off on a risk register. Whether you passed a point-in-time questionnaire.
The DBIR doesn't care about your documentation. The DBIR measures what happened.
Two findings in particular should keep auditees up at night.
Misconfiguration remediation takes almost eight months. The report tracked how long it takes organizations to resolve weak passwords and permission misconfigurations in third-party cloud environments. The median time to fix 50% of those findings was close to eight months. For MFA issues - which are broadly understood to be a critical control - only 23% of organizations fully resolved their findings.
If you passed a compliance assessment six months ago and haven't run a technical scan since, you almost certainly have unfixed misconfigurations sitting in your environment right now. The drift continues whether anyone is watching or not.
37% of organizations had an admin account with MFA disabled on IaaS. That is a point-in-time snapshot across a large dataset. Not organizations that had never thought about MFA - organizations that had presumably passed some kind of review. MFA is not a new concept. And yet more than a third had a disabled admin account when someone actually looked inside.
The practical implication: if your compliance program doesn't include continuous technical visibility into your Microsoft environment, you are documenting a posture that may not actually exist. You are certifying a configuration state that drifts the moment the auditor leaves. And now you have AI-assisted attackers probing that drift faster than ever.
The third-party risk numbers are the most important thing in this report for auditors, assessors, and vendor risk managers.
Third-party involvement in breaches is up 60% in a single year, now present in nearly half of all breaches. The DBIR breaks down three archetypes: the vendor in your software supply chain, the vendor hosting your data, and the vendor with a connection into your environment. All three are up. All three lead back to the same root causes: insecure authentication, excessive privilege, and misconfiguration.
This year, Verizon had access to data from inside third-party cloud environments directly - not just external scans. What they found: the core issues are MFA gaps and permission misconfigurations. Things that are entirely visible if you look, and almost entirely invisible if you rely on self-reported questionnaires.
This creates an uncomfortable question for anyone doing vendor risk management: if your assessment process relies on a SOC 2 report and a questionnaire, are you measuring the actual exposures driving breaches? SOC 2 tells you about controls as they existed at a point in time, as described by the vendor. It doesn't tell you whether MFA is actually enforced on admin accounts today. It doesn't tell you whether someone's configuration has drifted in the months since the audit. And it definitely doesn't tell you whether an AI-assisted attacker has already found the gap.
The auditors who close that gap - by incorporating technical evidence alongside documentation - are the ones whose assessments will actually predict breach risk rather than just certify it.
Here is the uncomfortable position the DBIR puts every organization in: attackers are using AI to operate faster, hit more techniques, and scale attacks that your existing controls were designed to stop at human speed. The right response is not to avoid AI in your security tools. It is to make sure the AI you're using is trustworthy enough to actually rely on.
That distinction matters more than it might sound. Raw AI output is accurate roughly 70% of the time. That is not good enough for security decisions. Senserva Trustworthy AI is built around closing that gap - through encoded domain expertise, enforced guardrails, and automated validation before output reaches your environment. The goal is 95%+ accuracy before any finding or recommendation is surfaced. Not because we claim AI is perfect. Because we enforce controls on it the same way we tell customers to enforce controls on their environments.
Siemserva is built on that foundation. When you run it against a Microsoft environment, you get a real-time read of your Conditional Access policies, MFA enforcement state, permission assignments, security defaults, and configuration posture across Entra ID, Intune, and M365. The things the DBIR keeps flagging as breach entry points - these are what Siemserva actually checks, through the Microsoft Graph API, against the same compliance frameworks (CISA SCuBA, MCSB) your assessors use.
A few things that map directly to the DBIR findings:
For auditees: Run Siemserva before your next assessment, not after. What you find will tell you whether the configuration state you're about to certify actually exists. It takes minutes, not half a day. The findings come with specific remediation steps, framed as WHAT is wrong, WHY it matters, and exactly HOW to fix it. If you've drifted since your last review, you'll know before your assessor does.
For assessors and vendor risk managers: Siemserva can be run against any Microsoft tenant. If your vendor assessment process needs to move from "please complete this questionnaire" toward actual technical evidence, Siemserva gives you a verified snapshot of security posture rather than a self-attestation - already mapped to the frameworks your review process speaks.
For both sides: The DBIR's eight-month misconfiguration remediation number exists because most organizations have no continuous visibility into whether their configuration matches their documented posture. Siemserva runs continuously. If something drifts, you know about it - not after an attacker found it first.
The 2026 DBIR is measuring breach reality, not compliance reality. And the gap between those two now has an AI accelerant on the attacker side.
The organizations that will close that gap are the ones that treat compliance as a floor, not a ceiling - that build in continuous technical visibility to stay honest about what is actually true in their environment - and that use AI tools they can actually trust to help them keep up with the pace of the threat.
That is what Senserva Trustworthy AI is for. Not to replace the audit process. To make sure the thing the audit process is measuring is actually true - and to put the same operational leverage the attackers have on your side of the table.