A test is a snapshot, not a state
A penetration test or vulnerability assessment describes an environment as it existed during the testing window — a specific set of dates, a specific configuration, a specific inventory of assets. It is a snapshot, and like any snapshot, its accuracy degrades from the moment it is taken. The report that arrives two weeks after testing concludes already describes an environment that no longer fully exists, because change has continued in the interim.
For organisations that test annually, or even quarterly, this creates a long gap during which the actual environment can diverge substantially from the one described in the last report — and during which nobody is looking, because the next assessment is months away and the last one is filed.
Where the drift comes from
Cloud environments change constantly, often through processes that never touch a change advisory board. Infrastructure-as-code pipelines deploy new resources automatically. Auto-scaling groups spin up instances that mirror a template which may itself have drifted from what was assessed. Developers provision test resources directly through cloud consoles, outside of any tracked pipeline, and those resources persist long after their original purpose has been served.
DNS is a similarly continuous source of change. New subdomains get created for campaigns, integrations, and internal tools on a rolling basis, and DNS records for decommissioned services are frequently left in place — sometimes pointing at infrastructure that no longer exists but remains claimable by anyone who registers the right cloud resource, a pattern known as subdomain takeover.
Third-party services add a layer that is entirely outside the organisation’s direct control. A SaaS vendor pushes an update that changes a default configuration. An integration partner modifies an API without notice. None of these changes appear in the organisation’s own change log, yet each one can alter the organisation’s actual exposure the same day it happens.
The cost of the gap
The practical consequence is that the highest-confidence security data an organisation has — the results of its last formal assessment — becomes progressively less representative of reality with every week that passes. By month six of a twelve-month testing cycle, a meaningful share of what the last report described no longer matches the current environment, and none of the change that occurred in between has been assessed at all.
This is not a hypothetical gap. Newly exposed assets, drifted cloud configurations, and abandoned DNS records are exactly the categories of finding that show up disproportionately often in breach post-mortems, precisely because they exist in the blind spot between scheduled assessments — created after the last test, and gone unnoticed before the next one begins.
Continuous monitoring as the connective tissue
The fix is not to test more often in the traditional sense — quarterly or even monthly penetration testing is expensive and still leaves gaps, just smaller ones. The more effective approach is continuous external monitoring that runs constantly between formal assessments, tracking the specific categories of change that create drift: new assets appearing under the organisation’s domains, DNS records pointing at resources that no longer exist, certificates approaching expiry, and newly disclosed vulnerabilities affecting software already identified as part of the environment.
This does not replace the depth that a formal penetration test provides — human testers finding logic flaws and chained vulnerabilities that automated monitoring will not catch is still necessary, and continuous monitoring is not a substitute for that expertise. What continuous monitoring does is keep the picture current in between those deeper assessments, so that the organisation is not relying on a six-month-old snapshot to represent an environment that has been quietly changing every day since.
Setting the right cadence
The practical target is to shrink the window between a change occurring and someone noticing it, for the categories of change most likely to matter — external exposure, DNS integrity, and known vulnerabilities in internet-facing software. Formal assessments remain essential for depth, for testing business logic, and for the kind of creative, chained attack paths that only a skilled human tester finds. Continuous monitoring is what fills the space between those assessments, so that the organisation’s understanding of its own exposure tracks the pace at which that exposure actually changes, rather than the pace at which the testing calendar happens to run.
Written by Jamal Hashi, CyberPost Advisory.