A point-in-time vendor audit fails because it certifies how secure a supplier was on the day it was tested, and attackers now weaponise newly disclosed vulnerabilities in days. Mandiant put the average time from disclosure to exploitation at five days in 2023, down from 63 days in 2018. Ivanti Connect Secure was exploited as a zero-day for five weeks before its maker disclosed the flaw. An annual assessment cycle cannot see inside that window. This post shows why the gap is architectural and what continuous third-party risk monitoring catches that an audit cannot.
Why do point-in-time vendor audits fail?
A point-in-time vendor audit fails because it measures a single moment while the vendor’s exposure changes every day. It is a static snapshot of the controls a supplier could evidence on the audit date. It says nothing about the vulnerability disclosed the following week, the service exposed to the internet last month, or the credential leaked yesterday.
Point-in-time assessment failure is what happens when a vendor is certified secure on one date and a new vulnerability is weaponised before the next assessment: the certificate is accurate the day it is signed and irrelevant a week later. The failure is architectural, not a question of auditing more often.
You cannot speed-run an annual cycle into relevance; more frequent audits only add snapshots, each ageing the moment it is filed. The other half is how fast that window closes.
How fast are new vulnerabilities exploited in 2026?
Newly disclosed vulnerabilities are now exploited in days, and a growing share before disclosure at all. VulnCheck found that nearly 29% of the vulnerabilities first exploited in 2025 were hit on or before the day their CVE became public. In the EU, ENISA attributes 21.3% of initial-access cases to vulnerability exploitation, with attackers “rapidly weaponising them within days of their disclosure.” Verizon’s 2026 Data Breach Investigations Report now ranks vulnerability exploitation as the single largest initial-access vector, at 31%.
In May 2026, Google’s Threat Intelligence Group reported the first zero-day exploit it believes was developed with AI, built for a mass-exploitation campaign. The same report describes a nation-state group “sending thousands of repetitive prompts that recursively analyse different CVEs and validate PoC exploits.” Exploit development that took a skilled team weeks is becoming a scripted, repeatable task. In the time it takes a vendor to answer “yes” to question 42 of your questionnaire, an automated exploit has already mapped its network.
Why doesn’t auditing quarterly fix it?
Auditing quarterly does not fix the problem, because a quarterly audit is still a snapshot and still relies on what the vendor reports. Move from annual to quarterly and the blind spot shrinks from twelve months to three. The exploit window is days.
The defender’s clock is the other half of the gap. Bitsight’s analysis of the CISA Known Exploited Vulnerabilities catalogue found critical flaws took a median of 137 days to remediate, with more than 60% still unpatched past CISA’s deadlines. Verizon’s 2026 report found only 26% of those known-exploited vulnerabilities were fully remediated during 2025. Set five days to exploit against 137 days to patch: the audit interval is irrelevant, because the exposure lives in the gap between the two.
Questionnaire vs. Reality
- Questionnaire Says: “We perform annual third-party risk assessments of all critical suppliers.”
- Reality Shows: Ivanti Connect Secure, a remote-access gateway used across thousands of corporate networks, was exploited as a zero-day for roughly five weeks before disclosure on 10 January 2024. Within six days a public exploit existed, CISA added the flaws to its KEV catalogue, and mass exploitation began; Censys counted 1,700 compromised devices. An assessment filed the previous November would have rated that vendor green the entire time. (CVE-2023-46805 / CVE-2024-21887.)
What does the 72-hour rule actually mean for your obligations?
The 72-hour rule is the clock regulators start the moment a breach is found, and three separate regimes set it.
Regime | Reporting obligation | Clock |
Notify the supervisory authority | Within 72 hours of becoming aware | |
Early warning, then full incident notification | 24 hours, then 72 hours | |
Intermediate report | Within 72 hours of initial notification |
You are given three days to explain a breach an attacker may have opened through a vendor you last checked a year ago.
The same regulators have already ruled against the annual snapshot. DORA requires financial entities to manage ICT third-party risk “as an integral component” of their risk framework, to keep a live register of every ICT provider, and ties termination rights to circumstances found “throughout the monitoring of ICT third-party risk” (Article 28). NIS2 makes supply chain security “concerning the relationships between each entity and its direct suppliers” an explicit, ongoing obligation. The UK’s NCSC sets “continuous improvement” as a core stage of supply chain security. Continuous third-party risk monitoring is the posture the rules now assume.
What does continuous third-party risk monitoring watch?
Continuous third-party risk monitoring watches a vendor’s external attack surface every day, reading the signals an attacker sees rather than the controls a vendor reports. Four signals matter most:
- KEV catalogue changes. When CISA adds a vulnerability to its Known Exploited Vulnerabilities catalogue, continuous monitoring re-checks every vendor against it within hours, not at the next audit.
- Exposed services. It tracks internet-facing VPN gateways, admin portals, and file-transfer servers as they appear, the same assets attackers found on Ivanti.
- Patch-latency drift. It measures the days between a CVE landing and a vendor fixing it against their SLA, and flags a vendor falling behind before a breach does.
- Stolen Sessions. It catches corporate session (pre-authenticated logins) surfacing in infostealer logs, an account-takeover route no questionnaire records.
Black Kite, the continuous cyber risk ratings platform Elasticito uses, examined the 50 vendors most widely shared across the Forbes Global 2000: 70% carry at least one unpatched CISA KEV on their public estate, 84% have a critical CVSS-8-plus flaw, and 62% have corporate credentials in infostealer logs. Even the Global 2000’s most-shared suppliers fail on the signals attackers use. Black Kite also found the average gap from a third-party breach to its discovery widened to 117 days in 2025: a compromise lands in days but hides for nearly four months, known only to the attacker.
Elasticito runs third-party risk management as continuous threat modelling. It scores each vendor daily against those signals and maps every finding to the attack path that reaches your data. The audit certificate stays a procurement floor; your team acts on the live signal.
FAQ
Why do annual vendor audits miss most real-world threats?
An annual audit records the controls a vendor could evidence on one date. It cannot see a vulnerability disclosed after the auditors leave, a service newly exposed, or a credential leaked into an infostealer log. Most real-world compromises exploit these post-audit changes. The audit can be accurate and the vendor exploitable at once, because the two measure different things.
What is a point-in-time audit, and why is it a problem?
A point-in-time audit certifies that a vendor’s stated controls operated during a defined window; a SOC 2 report or an ISO 27001 certificate is the common form. It is a problem because it certifies the past, not the present. When attackers weaponise new vulnerabilities in days, a certificate signed months ago describes a security posture the vendor may no longer hold.
Does DORA require continuous monitoring of third parties?
In substance, yes. DORA does not use the phrase “continuous monitoring”, but it requires financial entities to manage ICT third-party risk as an integral component of their risk framework, to keep a live register of every ICT provider, and to act on circumstances found throughout the monitoring of that risk (Article 28). NIS2 and the UK’s NCSC point the same way. An annual audit alone does not meet that standard.
What is the difference between continuous third-party risk monitoring and an annual audit?
An annual audit is a self-attested snapshot: the vendor describes its controls, an auditor samples evidence, and the result is fixed for a year. Continuous third-party risk monitoring is external and observed: it watches the vendor’s live attack surface every day: KEV exposure, exposed services, patch latency, leaked credentials. The audit answers “did the controls exist?” Monitoring answers “is the vendor exploitable right now?”
What monitoring would have caught the Ivanti or MOVEit attacks before an audit could?
Continuous external monitoring would have flagged both. The day CISA added the Ivanti flaws to its KEV catalogue, monitoring would have re-checked every vendor running Connect Secure and surfaced its exposed gateways. A scheduled audit would still have marked the vendor compliant. The signal exists before the breach; the audit arrives after it.
Conclusion: why an annual vendor audit can’t keep pace with AI-speed exploitation
An annual audit tells you a vendor was defensible on a past date; it cannot tell you whether they are exploitable today.
See what your last vendor audit missed when you join Elasticito on 15 July 2026 for Your Questionnaire Won’t Save You: Discover the Vendors Most Likely to Breach You Next.
Created: 2026-06-04 / Reviewed: 2026-06-04
