Continuous pentesting, because attackers don't wait for your annual.
Most breaches happen against attack surfaces that drifted in the eleven months between annual penetration tests. Continuous pentesting closes that gap with scheduled and on-deploy tests that produce the same evidence-backed findings as your annual engagement — fed back into the same dashboard and the same reports.
The problem with point-in-time penetration testing
An annual penetration test is a snapshot. It tells you what your external (or internal) attack surface looked like on a specific day in Q3, what was vulnerable on that day, and what was remediated before the report shipped. By the time the report lands, the snapshot is already stale: marketing has spun up two new subdomains, engineering has retired a service without updating DNS, an AD permission grant from a help-desk incident never got revoked.
Compliance frameworks know this. PCI DSS 4.0 explicitly calls out testing after "significant infrastructure or application changes" — the implicit acknowledgement that an annual cadence is insufficient between major changes. Continuous pentesting operationalizes that requirement instead of treating it as paperwork.
The right mental model is the one your engineering team already uses for monitoring: you wouldn't check whether your production database is up once a year. You don't check your attack surface once a year either.
Continuous pentesting in practice
The cadence below is what most SimpleSec customers land on after the first month or two. Start with whatever fits your operational appetite; the platform supports any rhythm you want to run.
External attack surface
Subdomains get registered. DNS records change. Marketing spins up a new microsite. A weekly external test catches drift before an attacker maps it for you.
App and API endpoints touched by the deploy
Continuous pentesting in CI/CD (the Pro add-on) tests the deploy delta against the same playbook a senior pentester would run. Most useful between the staging deploy and the production push.
Internal network (via WireGuard agent)
AD configurations drift. New admin accounts get created. SMB signing gets disabled on a forgotten host. A monthly internal pentest keeps the inside-the-perimeter picture current.
Human-led review on critical findings
Continuous pentesting handles breadth. A quarterly human review on high-severity findings handles depth — chained business-logic flaws, novel attack paths, anything the planner can't reason about.
Compliance pentest of record
PCI DSS, SOC 2, and others still require an annual penetration test of record. Continuous pentesting feeds that engagement with eleven months of context, so the annual is targeted, not starting from scratch.
What continuous pentesting catches that annual doesn't
Real examples of drift continuous pentesting surfaces between engagements. These are the patterns that show up in customer post-mortems often enough to be worth naming.
Subdomain takeover risk
A marketing team retires landingpages.acme.example but forgets to remove the DNS CNAME. The CNAME points to a third-party SaaS that's now reclaimable. Continuous pentesting flags the dangling DNS within a week; an attacker registering the SaaS account first would not flag it at all.
Re-exposed admin interface
Phpmyadmin was firewalled off after the last engagement. Six months later, a network change accidentally re-exposes it. Continuous pentesting catches the re-exposure on the next weekly test; an annual-only program finds out at the next audit.
New service, no hardening
Engineering spins up an internal analytics service on port 8080 with default credentials, intending to harden it next sprint. Two sprints later, it's still default. Continuous pentesting against the internal network surface flags it the next month.
Drift in AD permissions
Helpdesk needs DA temporarily to fix an incident. The temporary grant never gets revoked. Continuous pentesting via the WireGuard agent enumerates AD privileges monthly and surfaces the persistent over-permission.
Continuous pentesting without alert fatigue
The fastest way to make continuous pentesting useless is to fire a notification on every finding. SimpleSec ships an opinionated default: only critical and high severities trigger alerts, findings present on the prior engagement don't re-fire, and there's a 2–4 week baseline period before alerts go live at all. Customers report typical signal volume after baseline is 3–8 actionable alerts per month on a 100-host external surface.
Delivery is webhook-based: the same payload format the CI/CD integration uses, wired into Slack, PagerDuty, your SIEM, or a custom internal endpoint. The audit log records every notification, so you have receipts when a finding was raised, who acknowledged it, and when.
Continuous pentesting + quarterly humans = stacked coverage
The honest pitch for continuous pentesting: it gets you breadth and consistency. A senior pentester gets you depth and creativity. The two stack rather than compete.
The arrangement that works for most security teams: SimpleSec runs continuous pentesting weekly (external) and monthly (internal), surfacing the bulk of attack-surface drift and known vulnerability classes. A human pentester runs a quarterly review focused on the highest-severity findings and business-logic flaws on critical applications. Once a year, a full human-led engagement of record satisfies the compliance requirement.
The cost picture: continuous pentesting eats 80% of the workflow time that used to consume the human pentester's first week. The human's hours move to where they're actually differentiated — the work that requires reading an application like an attacker would.
Continuous pentesting — frequently asked
What is continuous pentesting?
Continuous pentesting is the practice of running penetration tests on a recurring cadence — weekly, daily, or on every deploy — rather than as a once-a-year engagement. The goal is to catch attack-surface drift (new subdomains, re-exposed services, AD permission changes) within days of the change rather than at the next annual review. SimpleSec is built for continuous pentesting: scheduled tests, CI/CD-triggered tests, and on-demand engagements all flow into the same dashboard and evidence chain.
Does continuous pentesting replace annual penetration testing?
No. Compliance frameworks (PCI DSS, SOC 2, HIPAA) still require an annual penetration test of record. Continuous pentesting feeds that annual engagement with months of context, so the auditor-facing report is grounded in real, current attack-surface data instead of starting fresh. The annual pentest also typically includes a human-led review of business-logic flaws, which continuous pentesting doesn't replace.
How often should continuous pentesting run?
The cadence most SimpleSec customers settle on: weekly external attack-surface tests, per-deploy testing on apps touched by CI/CD, monthly internal pentests via the WireGuard agent, quarterly human review on high-severity findings, and an annual pentest of record. Standard and Pro tiers permit unlimited engagements within scope, so the cadence is whatever your operational appetite supports.
What's the difference between continuous pentesting and continuous vulnerability testing?
Continuous vulnerability testing runs a fixed scanner template list against everything it sees, on a schedule. Continuous pentesting runs the same workflow a human pentester would — recon, enumeration, exploitation validation, and (with the WireGuard agent) post-exploitation — and produces evidence-backed findings, not just possible-issue reports. Testing shows you what might be wrong; pentesting confirms what an attacker could actually do.
Can continuous pentesting alert on new findings?
Yes. SimpleSec posts new findings to the engagement record as they land and supports webhook delivery for new critical and high-severity findings — the same webhook format used by the CI/CD integration. Customers wire this into Slack, PagerDuty, or their SIEM. The audit log records every notification.
Does continuous pentesting create alert fatigue?
It can, if you don't tune it. SimpleSec's approach: severity-gated alerting (only critical and high by default), deduplication against prior engagement state (a finding that was there last week isn't re-fired this week), and a baseline period of 2–4 weeks before alerts go live so the noise floor settles. Customers report typical signal volume after baseline is 3–8 actionable alerts per month on a 100-host external surface.
Related reading
Make continuous pentesting your default cadence.
Standard and Pro tiers permit unlimited engagements within scope. Schedule weekly external tests, per-deploy CI/CD tests, monthly internal tests — whatever rhythm your program needs.