What is continuous penetration testing?

Key takeaways

• Continuous penetration testing replaces the annual point-in-time engagement with a rolling cadence of human-led testing.
• It runs on a live attack-surface inventory: when something new appears, it gets tested; when something is remediated, the fix is validated.
• Continuous testing combines automation (scanning, attack-surface monitoring) with human exploitation; neither alone is enough.
• The output is a stream of exploitable, business-ranked findings, not a once-a-year report.
• For mid-market manufacturers, continuous testing is the digital component that pairs with periodic physical security audits inside a broader adversarial simulation program.

How is continuous penetration testing different from an annual pen test?

An annual pen test is a snapshot. A team arrives, scopes a target list, runs an engagement over one to three weeks, writes a report, and leaves. Findings reflect the environment as it was during that window. Anything that changed in the eleven months afterward (new services, retired services, configuration drift, new SaaS, M&A integration, a vendor's repo getting compromised) is unmeasured until the next year's engagement.

Continuous penetration testing inverts the model. The engagement is the program. Testing runs on a rolling cadence against a live inventory of in-scope assets. Three properties make the model continuous rather than just "more frequent":

1. The inventory updates. New external services, new SaaS tenants, new public-facing applications, new vendor connections, and changes to existing ones are picked up automatically and queued for testing.
2. Remediation is retested fast. A fix that lands today is validated within days, not next year. If the fix did not actually close the issue, the team knows immediately.
3. The team carries context across engagements. The testers know the environment, know prior findings, and can compare this quarter's exposure to last quarter's. A new vendor each year cannot do this.

Continuous testing does not replace a red team engagement. A red team produces a deep, objective-driven story across the full attack surface; continuous penetration testing produces a stream of exploitable findings as the environment moves. The two are complementary inside a continuous adversarial simulation program.

What is included in a continuous penetration testing program

A well-run program has six functional components:

1. External attack surface mapping. Automated discovery of internet-facing assets, including shadow assets (forgotten domains, abandoned subdomains, expired certificates pointing to old infrastructure, dev environments accidentally exposed, vendor-managed subdomains the organization does not realize it owns). See What is attack surface management (ASM)?.

2. Continuous vulnerability and configuration scanning. Both authenticated and unauthenticated, against external and internal assets. The output is raw signal, not findings. It feeds the manual layer above it.

3. Human-led exploitation and attack-chain construction. Where the program differentiates from "managed scanning". A scanner finds a vulnerable Confluence instance; a tester chains it with weak SSO settings, a permissive service account, and an exposed dev branch to demonstrate exfiltration of source code.

4. Identity and SaaS testing. External email security, MFA configuration, OAuth grants, federation trusts, conditional access policy gaps, and SaaS admin exposure. Identity is the dominant attack surface in mid-market environments; continuous testing must cover it explicitly.

5. Application testing. Web applications, APIs, mobile apps, and (where present) custom internal applications. Cadence varies: high-change applications get tested more often; static ones less often but more deeply.

6. Findings and retest workflow. Each finding tracked from discovery through triage, remediation, and validated closure, with evidence at each stage. The program produces continuous deliverables (monthly packet, quarterly review) rather than a single annual report.

The scope explicitly excludes social engineering and physical access; those are separate disciplines covered by phishing simulation, vishing, and physical penetration testing. A continuous program runs all of these in coordination, but they are not the same engagement.

Why mid-market manufacturers need continuous testing

The fit between continuous testing and the mid-market manufacturing buyer is structural, not marketing. Three reasons matter most:

1. The environment changes too fast for annual testing to mean much. A 50-to-500-person manufacturer in 2026 is moving payroll to a new SaaS, integrating an acquired plant's network, exposing a new customer-facing portal, onboarding a new ERP module, and adding a remote-vendor connection to an OT system. Three of those happen per quarter. None of them get tested in an annual engagement scoped six months ago.
2. The compliance baseline is rising faster than security spend. NIST SP 800-171 Rev 3, CMMC 2.0 Phase 2 enforcement, and increasingly stringent prime-contractor flowdowns expect continuous evaluation, not annual snapshots. Continuous testing is becoming the floor, not the ceiling.
3. Insurance pricing rewards continuous evidence. Carriers running continuous-underwriting models give credit for evidence that controls are continuously validated. An annual pen test report counts for less than a quarterly testing rollup with closure rates and time-to-remediate metrics. See What is cyber insurance underwriting? and What is continuous underwriting?.

For an owner or CTO deciding where the next dollar of security spend goes, the question is no longer "annual or no". It is "annual, or continuous, given that the environment changes faster than annual cadence can keep up with".

Examples of findings only continuous testing catches

Patterns that show up in continuous programs and stay hidden in annual ones:

• A retired marketing campaign's subdomain points at a now-orphaned cloud bucket. A scanner notices the takeover risk within days of the marketing tool being decommissioned. Annual testing would miss it for months.
• A new SaaS app gets onboarded, federated to the corporate IdP, and given broad scopes. Continuous testing finds the over-permissioned OAuth grant in the next sweep. Annual testing would miss it until the next year. See What is consent phishing (OAuth phishing)?.
• An EDR exclusion rule is added to fix a noisy alert and accidentally opens a coverage gap. A BAS regression flags the gap within hours; the manual testing layer constructs the attack chain that exploits it.
• A vendor pushes an update that exposes an admin API behind a known-default credential. Continuous external testing catches the API exposure before the credential is used.
• An acquired company's domain controller still trusts the parent's old PKI, with a stale signing cert. Continuous internal testing finds the cross-tenant trust path during a routine sweep.

Each of these is exploitable on the day it appears. None of them is in the report from the engagement that ran six months ago.

How to choose a continuous penetration testing provider

For a mid-market manufacturer evaluating providers:

1. Methodology, not platform. Some vendors sell a platform with self-service tests; some sell a managed service with human testers; some sell both. The right answer for mid-market is a managed service with platform-driven coverage as the floor and human expertise as the ceiling.
2. Named operators. Continuous testing builds value across engagements because the team carries context. Ask who is on the engagement, by name, and how the team retains context if a tester rotates.
3. Coverage of the surfaces you actually have. OT-adjacent IT, SaaS, identity, and external attack surface. Cloud-native testing without SaaS coverage misses where mid-market manufacturers actually live.
4. Integration with the existing stack. Findings should land in the team's workflow (ticketing, chat, SIEM), not in a vendor portal that no one opens.
5. Retest SLAs. When a fix lands, how fast does the retest run. Days is good; weeks defeats the point.
6. Honest scope boundaries. A provider that includes social engineering and physical access in "continuous penetration testing" is selling something else. Those are separate, valuable disciplines, but conflating them muddies expectations.
7. Report quality at three levels. Executive narrative (what changed, what to do), technical detail (reproduction steps, evidence), and compliance-friendly summary (annual auditor-ready package generated from the continuous data).
8. Total cost of operation. Beyond licensing: how much time the internal team spends triaging, integrating, and acting on findings. If the program needs a dedicated FTE to function, build that into the comparison.

Best practices for triaging continuous testing findings

A continuous program produces a stream of findings. Without a workflow, the stream becomes noise.

1. Sort by exploitability and business impact, not CVSS. A medium CVSS finding that the tester chained into wire-fraud-adjacent access is more important than a critical CVSS in an isolated dev environment.
2. Tag findings by attack chain. Many "small" findings become large when chained together. Tagging at discovery time makes the chain visible at quarterly review.
3. Set time-to-triage SLAs. Findings should be triaged within 24 to 72 hours of arrival. Older than that and the program is signaling that the findings do not matter.
4. Distinguish remediation from compensating control from accepted risk. Each has different long-term cost; conflating them creates technical debt.
5. Loop findings into the incident response plan. Each finding is a chance to test whether the IR plan covers the scenario.
6. Track closure rate and time-to-remediate as program KPIs. These metrics are the substance of an insurance renewal package and the most credible evidence of program maturity.
7. Re-test on a fixed cadence even when nothing changed. Drift happens. Quarterly re-validation of every closed finding catches regressions before they become incidents.

Continuous penetration testing FAQs

Is continuous penetration testing the same as automated scanning?

No. Automated scanning finds known vulnerabilities. Continuous penetration testing layers human exploitation, attack-chain construction, and validation on top of scanning, so the output is exploitable findings ranked by business impact rather than a CVE list.

How often should retesting happen?

In a continuous program, remediation is retested as soon as the fix is in place, typically within days. The full surface is re-evaluated on a rolling cadence so every asset is touched at least quarterly, with high-risk surfaces (external attack surface, identity, exposed services) re-tested more often.

Does continuous testing satisfy compliance requirements?

It satisfies and often exceeds the annual penetration test requirement found in frameworks like NIST CSF 2.0, NIST SP 800-171, CMMC 2.0, ISO 27001, and PCI DSS. The deliverables (scope, methodology, findings, remediation evidence) need to be packaged for the auditor; a continuous program produces the data naturally as a byproduct.

What is the difference between continuous pen testing and BAS?

BAS validates whether existing controls catch known attacker techniques. Continuous penetration testing finds new exploitable weaknesses, constructs attack chains a real adversary would use, and tests business outcomes (data exfiltration, wire fraud, OT access). BAS measures controls; continuous pen testing measures the actual attack surface. See What is breach and attack simulation (BAS)?.

How ARG runs continuous penetration testing alongside physical audits

ARG runs continuous penetration testing as the digital backbone of a broader adversarial simulation program. It is paired with periodic on-site physical engagements and continuous social engineering simulation, not delivered alone.

The continuous layer is operated by James Wall on infrastructure ARG owns and controls. External attack surface monitoring, identity and SaaS testing, application testing, and BAS-style control validation run year-round. Findings are mapped to MITRE ATT&CK techniques and logged into the same workflow the social engineering and physical findings feed into.

On-site engagements, delivered by David Ashby, happen on a one- or two-year cadence depending on the client. During the on-site week, the continuous layer's findings inform where to look: a recurring identity drift becomes a privileged access manipulation test; a SaaS exposure becomes a vendor-impersonation pretext; an EDR coverage regression becomes a real exploit chain demonstrated end to end.

The deliverable is a single program with one finding backlog, one trendline, and one remediation rhythm. The client sees the same operators week after week, which means findings accumulate context instead of starting from zero each time a new vendor walks in.

For founding clients, the continuous testing layer is included in the monthly retainer alongside continuous social engineering simulation. Pricing is locked for two to three years.

Apply as a founding client or see how the engagement works for the full delivery cycle.