Third-party involvement in confirmed data breaches doubled in a single year, from 15% to 30%, according to the Verizon 2025 Data Breach Investigations Report. The same report covers 12,195 confirmed breaches, which makes the jump hard to dismiss as a sampling artefact. For a mid-market CISO whose board has started asking about supply chain posture, the practical question is no longer “should we assess our vendors?” but “what does an assessment actually need to cover?”
This piece is written for that question. It walks through five areas a real third-party security assessment should examine, why the once-a-year vendor questionnaire keeps missing the same risks, and where continuous testing fits into a working programme. The framing is operational, not regulatory — though DORA (for financial services in the EU) and NIS2 are accelerating the conversation in 2026.
Why the annual questionnaire stopped working
The standard vendor security questionnaire is a self-attestation document. The vendor fills it in, signs it, and the buyer files it. It tells the buyer what the vendor says its controls look like at a moment in time. It does not test those controls, and it does not catch what changes between renewals.
The 2026 study from Panorays of 200 CISOs found that 85% still cannot see threats originating from their vendor ecosystem, even though 60% reported that third-party incidents are rising. Only 21% had actually tested a crisis response plan that accounts for a third-party failure. Sixty-six percent said their GRC platforms were ineffective for the job.
Two patterns explain most of that gap.
First, attackers have moved beyond the build pipeline. The Rapid7 February 2026 report on the Lotus Blossom (China-nexus) compromise of Notepad++ update infrastructure showed that supply chain risk now reaches into hosted update mechanisms and shared environments. A questionnaire about secure development practices does not surface a compromised update server.
Second, the initial-access mix has shifted. Mandiant’s M-Trends 2025 report puts exploits at 33% of investigated incidents and stolen credentials at 16% — the first time credentials have ranked that high. Many of those credentials come from partner environments. A point-in-time questionnaire cannot detect a credential leak that happens three months after it was signed.
A real assessment is a tested view of how a vendor would actually behave under attack, not a self-graded report card.
What a real assessment covers
The five areas below are what CTDefense looks at on a vendor security assessment for mid-market clients. Each is something an annual questionnaire tends to underweight or skip.
1. The vendor’s external attack surface
The first thing the team examines is what the vendor exposes to the internet on the buyer’s behalf. That includes the SaaS tenant or hosted instance, any public APIs the buyer integrates with, the vendor’s update or download infrastructure if it ships software into the buyer’s environment, and the marketing-site subdomains that often share authentication or identity infrastructure with the production application.
Findings in this area tend to be unglamorous and high-impact: forgotten staging environments, expired certificates on integration endpoints, exposed administrative consoles, and unauthenticated APIs that were meant to be internal.
The vendor’s own attack surface scan rarely captures these because the vendor scans what it owns, not what it has stood up for one specific customer.
2. Identity, credentials, and shared access
The team then looks at how the vendor and the buyer share identity. This is where the stolen credentials vector lands in practice. The questions are concrete: does the vendor use single sign-on into the buyer’s tenant, or does it have a long-lived service account with broad rights? Are vendor staff using personal accounts to access buyer systems? When a vendor employee leaves, who deprovisions their access, and how quickly?
The assessment also examines the reverse direction: which buyer-side credentials, API tokens, or signing keys live inside the vendor’s systems, and how are they protected. A breach of the vendor that exposes those secrets is functionally a breach of the buyer.
This area is the single most common source of preventable third-party incidents, and it is the one a questionnaire is least likely to test.
3. Update, build, and deployment paths into the buyer’s environment
If the vendor ships code, agents, or updates into the buyer’s environment, those paths are part of the buyer’s attack surface. The team examines how updates are signed, how the signing keys are protected, where update files are hosted, and how the buyer’s systems verify integrity before installing.
This is where the Notepad++ case is instructive. The malicious payload was distributed selectively from October 2025 onwards through the legitimate update infrastructure. Buyers who trusted the update channel without independent verification had no signal until external researchers raised it.
For SaaS vendors, the equivalent question is what changes the vendor can push into the buyer’s tenant without notice — feature flags, configuration changes, integrations enabled by default — and how the buyer is notified when those changes happen.
4. Data flow and shared environments
The team maps what data the vendor processes, where it is stored, who else has access to the same environment, and how the data is segregated from the vendor’s other customers. For a multi-tenant SaaS, the relevant tests are around tenant isolation: can a misconfigured permission, an IDOR-style flaw, or a stale OAuth scope let one tenant read another’s data?
This area also covers logging. Many breach investigations stall because the buyer has no log access into the vendor’s environment and the vendor’s retention is shorter than the dwell time. Mandiant has reported median dwell times in the double digits of days for several years; if vendor logs only go back fourteen days, the buyer’s investigators are flying blind.
5. Incident response and contractual reality
The last area is what actually happens when the vendor has a security incident. Not what the contract says — what the runbook does. The team reviews notification timelines, the buyer’s contractual rights to forensic access, who pays for what, and whether the buyer’s own incident response plan has ever been exercised against a third-party scenario.
The Panorays finding that only 21% of CISOs have tested a crisis response plan covering a third-party failure is the gap this section is built to close. A tabletop run jointly with the vendor — even a short one — surfaces in an afternoon what the contract clauses miss.
Why continuous testing beats annual review
Vendor risk does not stay still between renewals. A new feature ships, a credential leaks, a sub-processor changes, an update server is compromised. The annual questionnaire captures none of this.
Research from NCC, published in its State of Supply Chain Security 2025 report, surveyed over 1,000 respondents and found that 45% had already suffered a supply chain breach in the previous twelve months, while only 66% regularly evaluate supplier risk. That is a wide gap between exposure and attention.
A working programme combines three things:
- A point-in-time deep assessment when a vendor is onboarded or a critical relationship is renewed.
- Continuous external monitoring of the vendor’s attack surface, certificates, and credential exposure on the buyer’s behalf.
- A short, scheduled retest — quarterly for critical vendors, annually for the rest — that focuses on what has changed.
This is also where DORA and NIS2 push in the same direction. Both regimes expect the buyer, not the vendor, to demonstrate ongoing oversight of ICT third-party risk. A signed questionnaire does not meet that bar.
How CTDefense works through this with clients
CTDefense runs third-party security assessments as a paired exercise: a technical assessment of the vendor’s exposed surface and integration points, plus a workshop with the buyer’s security and procurement teams to translate findings into a renewal or remediation plan. The team writes findings in business language, prioritised by what the buyer can actually act on, and reviews the same vendors on a continuous cadence rather than as a one-off.
For mid-market organisations in finance, healthcare, manufacturing, and technology, the practical starting point is the top ten vendors by data sensitivity or operational dependency. CTDefense continues to support these teams with vendor security assessments, continuous monitoring, and joint tabletop exercises against third-party scenarios. Similar organisations are encouraged to take a close look at their own top-tier vendors — particularly identity, update paths, and incident-response readiness — well before the next audit cycle asks them to.