What Has Changed Since the Last Penetration Test?
A common question after a major release or significant application change is whether a full retest is required. Not every release alters the attack surface. New roles, integrations, APIs, authentication flows, or public-facing functionality usually do. Visual updates and routine bug fixes usually do not.
Between scheduled penetration tests, teams often want a lighter way to see what has changed without commissioning a full assessment every cycle.
What change detection covers
Change detection identifies meaningful differences in a web application over a custom interval. It can run credentialed (with valid test accounts) or non-credentialed. The output is a summary of new or substantially altered surfaces rather than a full vulnerability report. Some teams use it for visibility only; others request limited analysis of the changes that matter.
When it is useful
- After a major release that adds roles, integrations, or public-facing functionality.
- Between annual or semi-annual penetration tests.
- When you need evidence of monitoring for significant changes (for example, PCI-related significant-change expectations).
- When a full retest of every release is not practical.
It does not replace a penetration test. It reduces the blind spot between them and helps decide when a scoped or full retest is warranted.
Change detection is part of High Bit’s PTaaS work and has been included in those engagements. It can also be scoped when the primary need is visibility between tests. All tooling, resources, and data remain on High Bit’s private, self-hosted systems. High Bit also offers per-client data isolation. Nothing is sent to a third-party cloud platform; client data does not leave High Bit networks except when you access your reports. See the change detection page or the comparison article.