Yes, in most cases you need to retest after a major software release. A pentest is a snapshot in time: as soon as the software changes, the attack surface changes too. New features, modified authentication logic, or updated API integrations can introduce vulnerabilities that didn’t exist at the time of the previous test. The questions below help you determine when, how, and how often you need to do this.
Which changes in a release justify a new pentest?
Not every software update calls for a full new penetration test, but certain changes expand the attack surface to such an extent that testing becomes necessary. Think of new authentication or authorization logic, new external integrations or API connections, changes in how data is stored or processed, and new user roles with associated permissions. For these types of releases, retesting is not a luxury but a requirement.
A useful rule of thumb: ask yourself whether an attacker has different opportunities with the new release than before. If the answer is yes, that justifies a new test. Concrete examples of release changes that almost always require a pentest after a software release:
- New login methods or SSO integrations
- Addition of payment functionality or integrations with financial systems
- Changes to cloud configurations or infrastructure (for example new Azure roles or S3 buckets)
- Expansion of the system to new user groups or external parties
- Migrations to a new technology stack or framework
Minor bug fixes or purely visual changes generally do not justify a full pentest. But even then, a targeted vulnerability scan can be useful to check whether any unintended side effects have occurred.
How does a delta pentest differ from a full pentest?
A delta pentest focuses exclusively on the changes relative to a previously tested version of the software. A full pentest reassesses the entire system, including components that have not changed. The difference lies in scope, turnaround time, and cost: a delta pentest is faster and cheaper, but assumes that the previously tested components are still secure.
That last assumption carries risks. Even unchanged components can become vulnerable due to new attack techniques, modified dependencies, or a different environment. A delta pentest is therefore most suitable when:
- The previous full pentest was conducted recently (preferably no more than six months ago)
- The changes are well documented and clearly defined
- No major infrastructural changes have taken place alongside the release
Are there doubts about the scope of the changes, or has the previous test been some time ago? Then a full penetration test is preferable. A delta pentest saves time and money, but should never become an excuse to test less thoroughly than the situation requires.
Why is an annual pentest insufficient after frequent releases?
An annual pentest is insufficient when an organisation deploys software multiple times a year, because each new release potentially introduces new vulnerabilities. The test results from January are already outdated by June if five releases have taken place in the meantime. An annual penetration test then provides nothing more than a snapshot of a moving target.
Cybercriminals do not operate on an annual schedule. They continuously scan for new weaknesses, including in software that has just been released. Organisations that release regularly but only test once a year run an elevated risk for most months of the year without knowing it.
The problem grows as releases become more frequent. Teams working with agile or DevOps methodologies can deploy changes weekly or even daily. In that context, the question is not whether you should test more often, but how you organise that structurally. Continuous penetration testing provides an answer: instead of an annual snapshot, you create an ongoing picture of your security posture, aligned with the pace of your development cycle.
What is the difference between a pentest and a vulnerability scan after a release?
A vulnerability scan after a release automatically detects known vulnerabilities based on a database of public security issues. A pentest goes further: a human ethical hacker actively investigates how vulnerabilities can be combined into an attack path, just as a real attacker would. A scan tells you what is wrong; a pentest shows you what is possible.
This distinction is crucial when assessing a new release. Suppose an update introduces a new API integration with an incorrect permission configuration. A vulnerability scanner may not flag that configuration as critical, because the finding scores low in isolation. A human pentester, however, sees how that misconfiguration can be combined with an existing weakness elsewhere in the system, together leading to full access to sensitive data.
Attackers think in attack paths, not in isolated findings. That is precisely why an automated scan after a release is useful as a first check on basic hygiene, but a manual pentest is necessary to understand what an attacker can truly achieve. Read more about this difference on the page about cyber research.
How do you structurally embed pentesting into your release process?
Structurally embedding pentesting into a release process means determining in advance which types of changes require which level of testing, and recording those agreements in your development cycle. The goal is that security is not an afterthought following a release, but a fixed step in the process itself.
A practical approach works with three levels:
- Automated scans with every release: Integrate vulnerability scanning into your CI/CD pipeline so that known vulnerabilities are automatically detected before production.
- Delta pentests for significant changes: Establish clear criteria for which changes require a targeted test. Document the scope per release and have an ethical hacker assess the new components.
- Full pentests at fixed intervals: Schedule a full penetration test at least once or twice a year, regardless of release frequency. This catches blind spots that fall outside the scope of delta tests.
Organisations with a high release frequency benefit from a model in which pentests are scheduled as part of sprint planning or the release calendar, not as a separate activity afterwards. This prevents security from always lagging behind.
An additional benefit of this approach is that teams build security awareness as a natural part of the development process. Developers who know their code will be tested think differently about the choices they make while building.
How Q-Cyber helps with pentesting after a software release
At Q-Cyber, we understand that a software release is not the endpoint of your security effort, but a new starting point. We help organisations structure and implement pentesting effectively, tailored to their release cadence and risk level. What we offer:
- Manual pentests carried out by certified ethical hackers, focused on attack paths rather than isolated findings
- Delta pentests for targeted assessment of new or modified functionality after a release
- Continuous-Q®: an ongoing testing programme for organisations that want continuous insight into their actual vulnerabilities, not just once a year
- Independent advice on how to structurally embed security into your development process, without dependency on software vendors
- Clear reports with concrete priorities, so that after every test you immediately know where action is required
Want to know whether your organisation needs to be retested after a recent release, or how to structurally set up pentesting? Get in touch with us and we will be happy to think along with you.