How Often Should You Do VAPT? A Practical Schedule
The honest answer to "how often should we do VAPT" is: at least once a year, and again whenever something important changes. A test is a photograph of your systems on the days it was done. New code, a new server or a new vulnerability makes the photograph out of date.
Buying guides · By Thimmagurudu Bathini · Published · 3 min read · Last reviewed
The baseline: once a year
Annual testing is the usual minimum, and it is what most customer contracts, ISO 27001 and SOC 2 programs and many regulators expect. A yearly test gives you a regular check on your whole environment and a report you can show customers and auditors.
Test again when something important changes
A calendar date is a poor trigger on its own. These events should start a test, or a focused retest:
- A major release, a new module or a new payment or login flow.
- A move to a new cloud account, hosting provider or architecture.
- A merger, a new office or a new remote-access system.
- A security incident, or a near miss.
- A new, serious vulnerability in software you use.
- A customer, auditor or regulator asking for evidence of testing.
A simple schedule by risk
| What you run | Suggested testing |
|---|---|
| Internet-facing systems and public websites | At least yearly, with a vulnerability scan more often between tests |
| Customer web application, mobile app or API | Yearly, and after each major release |
| Payment, health or identity data | Yearly in depth, and more often as the release cadence needs |
| Internal network and Active Directory | Yearly, or after big changes to the network or identity setup |
| Apps released many times a month | Automated checks in the pipeline, and a manual test on a schedule |
What the rules ask
Different frameworks name different intervals. PCI DSS asks for external and internal penetration testing at least once every 12 months and after significant changes. ISO 27001 and SOC 2 do not prescribe a number, and auditors usually look for a regular, risk-based program and evidence of fixing findings. Check your contract and the current text of any standard that applies to you: our pages on PCI DSS, ISO 27001 and SOC 2 explain how testing fits each one.
Scans between tests
A vulnerability assessment or automated scan between full tests keeps the picture current for less money. It finds known issues, exposed services and missing patches. It does not test business logic, so it complements a manual test. See vulnerability assessment.
Retesting is part of the cycle
A test that ends with a report has done half its job. After your team fixes the findings, a retest confirms each fix works. Plan it into the schedule and the budget from the start. Our cost guide explains how scope and retesting affect price.
Mistakes to avoid
- Testing only before an audit, then ignoring the findings until the next one.
- Testing production only once, then releasing ten major versions untested.
- Treating a scan as a penetration test.
- Not keeping the reports: you will need to show the date, scope and fixes.
Build your schedule
List your applications and networks, mark the ones that hold customer data or money, and add the date of each one's last test. Anything without a date in the last twelve months goes first. We will help you turn that list into a plan: request a scoping call, or read our methodology.
Written by Thimmagurudu Bathini, BERRY9 IT SERVICES PRIVATE LIMITED, Hyderabad. Questions about your own systems? Request a scoping call or call +91 86868 92922.
Plan your next security test
Tell us what needs testing and when you need it done, and we will propose a scope and timeline. We respond within 24 hours. If you would rather talk first, call or write to us.
- +91 86868 92922
- contact@berry9.com
- H.No: 8-3-945/A/12 & 13, Sri Venkata Sai Nest Apartments, Nagarjuna Nagar Colony, Yellareddyguda, Hyderabad 500073, Telangana