How should teams handle vulnerabilities that appear between scheduled pentests?

Why intermittent pentest findings need a live-vulnerability response

Pentests are point-in-time checks, so a vulnerability that appears after the last assessment is not a “gap in the report”; it is current exposure that needs a response path now. Teams should treat the finding as a signal to validate whether discovery, change control, and ownership assignment are keeping pace with the environment, especially when assets, code, or configurations change between cycles.

The practical question is not whether the next scheduled test will find it, but whether the organisation can see and triage it before it is exploitable for long enough to matter. That means the vulnerability management process has to behave more like continuous assurance than annual or quarterly audit theatre.

Where teams still rely on manual, calendar-based testing, they tend to discover weaknesses only after attackers or adjacent controls do. A better model is to connect scanning, asset inventory, change detection, and remediation routing so that new exposure is surfaced close to the moment it appears, not when the next engagement is booked.

What “between pentests” should change in the operating model

The main shift is to separate assessment cadence from remediation cadence. Pentest scheduling can remain periodic, but triage and verification should be event-driven when something material changes, such as a new release, a configuration drift, a newly exposed service, or a third-party update that alters attack surface.

This is where continuous discovery matters. If the environment is dynamic, the assessment model must watch for new hosts, endpoints, APIs, packages, certificates, and externally reachable services, then route any newly relevant weakness to the owner who can act on it. Waiting for the next formal test cycle delays ownership, and delayed ownership usually becomes delayed mitigation.

Teams also need targeted revalidation. A fix is not fully real until the affected control or asset is checked again in the changed state, because many weaknesses reappear through incomplete rollout, environment mismatch, or configuration regeneration. In practice, “closed” should mean “verified in the live environment,” not merely “recorded as addressed.”

For exposure that is already known or plausibly exploitable, the CISA Known Exploited Vulnerabilities Catalog is a useful external trigger point for prioritisation because it distinguishes actively exploited issues from backlog noise. That matters when teams need to decide which findings deserve same-day action rather than standard queueing.

What good handling looks like when a gap appears

Good handling starts with speed of attribution. The organisation should be able to answer three questions quickly: what changed, which asset is affected, and who owns the fix. If any of those answers are slow, the vulnerability will age in place and the risk window will widen even if the eventual remediation is technically strong.

Good handling also means the finding is treated as a lifecycle event, not just a scan result. A newly emerged weakness should trigger a small but disciplined sequence: confirm scope, assess exposure, assign ownership, set remediation priority, and recheck after the change is deployed. That sequence is more effective than waiting for a large batch review because it compresses the time between discovery and control.

When teams have strong change management, they can often use the same mechanism that introduced the weakness to validate the fix. If the issue appeared because of deployment drift, configuration change, or dependency update, the remediation process should include a control that catches the same class of drift the next time it occurs.

At the operational level, the aim is to reduce blind time. The shorter the period between the vulnerability appearing and the organisation’s awareness of it, the less opportunity there is for misuse, lateral movement, or repeated exposure across similar assets.

Risk and Threat Considerations

Between-schedule vulnerabilities create a control gap that attackers and misconfigurations can both exploit. The risk is not only that a weakness exists, but that the organisation may not know it exists long enough for it to be probed, chained, or mirrored across related systems before the next planned assessment.

Failure mechanism: Point-in-time pentests can miss newly introduced exposure when assets, code paths, or configurations change faster than the assessment cycle. That creates a blind period where ownership is unclear, remediation is delayed, and the same weakness can persist across multiple deployed instances.

Impact: Exposure time increases, exploitable issues stay live longer, and response becomes reactive instead of preventive. In practice, that raises the likelihood that a weakness is discovered by adversaries, by incident response, or only after it has already spread into production.

Practitioner Guidance

What to prioritise: Prioritise the process that shortens exposure time, not the next report date. If a finding appears after a pentest, route it through the same urgent triage path you would use for a newly disclosed high-risk issue.

What to verify: Verify that the environment has continuous or event-driven discovery, a named owner for each exposed asset, and a revalidation step after remediation. If those three things are missing, the pentest programme is probably measuring more than it is governing.

Common mistake: Teams often close the ticket when the fix is deployed but never confirm that the live system matches the intended state. The stronger control is not “we patched it”; it is “we can prove the exposure no longer exists where it mattered.”

Practitioner takeaway: Between-pentest findings should be handled as live operational risk, because the real objective is to reduce the time a weakness remains unseen and actionable, not to maximise the number of weaknesses captured on the next scheduled engagement.

Related resources from NHI Mgmt Group

• How should security teams handle cloud misconfigurations that appear between scheduled scans?
• How should security teams handle risks from AI browser extensions?
• How should teams handle secrets that have no obvious owner?
• How should security teams use continuous adversarial testing to reduce the exposure gap between scheduled pentests?