Pen Test Once a Year, DAST and SAST the Rest of the Year

CISA's Known Exploited Vulnerabilities catalog listed 1,748 entries on 18 October 2026, with the newest added on 16 October. Verizon's 2026 report counts vulnerability exploitation as the leading way breaches begin, at 31%. Software changes weekly and new flaws are disclosed daily, while a penetration test is a snapshot taken on a few days of the year.

So "how often should we test?" has two answers. A person should try to break your product at least annually and after major changes. Automation should check it every day in between.

What's affected

Any company asked a question like "Do you test your application regularly?" The PCI Security Standards Council's penetration testing guidance gives the clearest published cadence. Its comparison table says vulnerability scans run at least quarterly and after significant changes, and penetration tests at least annually and upon significant changes. Some entities must test more often, so check the standard that applies to you.

What counts as significant? The guidance says PCI DSS does not prescribe it. It depends on your risk assessment and environment: if a change could affect the security of the network or allow access to sensitive data, you may treat it as significant. Penetration testing a significant change is meant to confirm that controls assumed to be in place still work after the change.

SOC 2 sets no number. A CPA firm's published guidance says neither pen testing nor vulnerability scanning is strictly required by the Security criteria and that frequency should come from a risk assessment. CC7.1 does refer to periodic vulnerability scans, and your auditor will want to see whatever you commit to in your own policy.

How to check if you're exposed

List what actually ran in the past twelve months:

• Date of the last penetration test and whether the retest is closed.
• Whether any significant change shipped since: new authentication system, new tenant model, new public API, major cloud migration.
• Whether SAST, DAST and dependency scans run on a schedule or only when someone remembers.

Any "no" is a gap you can fix with the calendar below.

What to do now

Adopt a cadence and write it into your vulnerability management policy so the questionnaire answer is simply true:

That calendar is a recommendation, not a standard. Adjust it to your risk and write down your reasons.

Here is a ZAP baseline run you can drop into CI. ZAP's baseline scan spiders the target for one minute by default, waits for passive scanning, and reports. Its documentation says it does not perform actual attacks, runs in a few minutes at most and is intended for CI/CD, even against production sites.

docker run -v $(pwd):/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://staging.example.com -r zap-report.html

For dependencies, the free scan at gold.safeguard.sh/scan takes a package.json, requirements.txt, CycloneDX or SPDX file in the browser and checks up to 100 dependencies without the file leaving your machine. It is a quick way to see the software composition half of the picture.

Do not forget the third leg. Static and dynamic tests cover your own code and your running app, but most of what ships is other people's packages. Dependency checks belong in the same calendar, and a KEV match on a package you ship should jump the queue, because it means attackers are already using the flaw. Reachability matters here too: whether your code actually calls the vulnerable function changes how urgent the fix is.

How to avoid this trap

• Do not treat the annual test as your whole program. The report is dated the day it is issued and ages with every deploy.
• Do not run only passive scans and call them DAST. Baseline scans find hygiene issues; authenticated, active testing finds more.
• Do not define "significant change" after the fact. Write the definition into policy so no one argues about it later.
• Do not skip the retest. Findings without verified fixes are open risk.

Why it matters

SAST, DAST and penetration testing see different things. SAST reads source code and finds flaws at the line where they are written. DAST attacks the running application from outside and finds what only appears at runtime, such as headers, exposed paths and misconfigured behavior. A person finds what neither can: broken business logic, chained weaknesses and access control mistakes that look like valid responses.

Used together, they give you evidence that testing is continuous. Used alone, each has blind spots, which is exactly what a careful customer reviewer is probing when they ask how often you test.

Try it yourself

Copy the calendar into a document and add the name of the person or system responsible for each line. Blank cells are your first improvement tickets. Then run the ZAP baseline command once against staging and read the report.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CISA Known Exploited Vulnerabilities Catalog
• Verizon 2026 Data Breach Investigations Report
• PCI Security Standards Council, Information Supplement: Penetration Testing Guidance v1.1 (September 2017)
• Linford & Company: Vulnerability Assessment vs Penetration Testing for SOC 2 Audits
• ZAP baseline scan documentation