Continuous penetration testing

What is continuous penetration testing?

It is penetration testing that starts itself. An annual test covers the system as it stood during one fixed window; a continuous program re-tests whenever something changes or a timer fires, and keeps the results current. The testing can be automated, human, or a mix, but the trigger does not depend on someone booking an engagement.

The label is used loosely. The post on continuous penetration testing vs annual pentests walks through the offerings sold under the name and how to tell them apart. This page covers the mechanics: triggers, how it plugs into delivery pipelines, and how it relates to compliance tests.

What triggers a test?

Three kinds of trigger, and a mature program uses all three.

Release and change triggers keep the gap between "exposure appears" and "exposure is tested" short. The schedule catches what the other two miss: drift in unchanged systems, new techniques against old code, and assets nobody registered. Change detection depends on knowing your attack surface, so discovery is part of the program.

A trigger policy makes this concrete. This is a generic example, not any product's format:

# pentest-triggers.yaml (illustrative)
scope:
  include: ["*.app.example", "api.example"]
  exclude: ["status.app.example"]
triggers:
  - on: deploy
    environments: [staging]
    test: changed_services        # routes and roles touched by the diff
    block_release_on: [critical]
  - on: asset_discovered
    types: [subdomain, open_port, api_route]
    test: new_asset
    notify: security-oncall
  - on: schedule
    cron: "0 2 * * 1"             # weekly, Monday 02:00 UTC
    test: full_scope
retest:
  on_ticket_state: ready_for_retest
reporting:
  keep_results_months: 12

Two choices in that file carry most of the risk. Blocking a release on a confirmed critical finding is a policy decision, not a technical one, and it needs an owner. Keeping results for 12 months matches what PCI DSS 11.4.1 asks for testing and remediation records.

How does it fit CI/CD?

It runs next to the pipeline, not inside every build. Static analysis and dependency checks run on each commit because they are fast and read code. A penetration test needs a running system, valid accounts and minutes to hours of work, so the usual pattern is:

1. The pipeline deploys to a staging environment that mirrors production.
2. A deploy event is sent to the testing system with the changed services.
3. Tests run against staging with test accounts in two tenants.
4. Confirmed findings open tickets; a critical can fail a release gate.
5. When a fix ships, the ticket state triggers a pentest retest.

Testing production directly is possible, but it needs agreed rate limits, test tenants and a rollback plan written into the rules of engagement. See CI/CD pipeline security for the pipeline itself as a target.

Does it replace the annual compliance test?

Not by itself. The major frameworks set a minimum frequency and a tester requirement, and continuous testing sits on top of those.

• PCI DSS v4.0.1, 11.4.2 and 11.4.3. Internal and external penetration testing is performed "at least once every 12 months," "after any significant infrastructure or application upgrade or change," and "by a qualified internal resource or qualified external third party," with "organizational independence of the tester." The PCI SSC's guidance says what counts as significant "is not prescribed by PCI DSS" and depends on the entity's risk assessment. A continuous program produces a record of testing after changes. Whether that record counts toward the after-change clause is the assessor's call, and both clauses still require a qualified, independent tester.
• FedRAMP. Section 7 of the Penetration Test Guidance requires a 3PAO test no more than six months before the SAR for initial authorization, then "at least every 12 months" unless an authorizing body approves otherwise with documented rationale. Section 8 requires that all penetration test activities be performed by a 3PAO.
• SOC 2. The Trust Services Criteria set no pentest frequency. Penetration testing appears as an example in a CC4.1 point of focus on ongoing and separate evaluations, alongside certifications and internal audit.

In practice, continuous results make the annual test more useful. The tester can start from a current list of known findings and spend the engagement on depth.

What are the trade-offs?

Continuous testing buys freshness and costs depth per run.

• Depth. Targeted runs on a diff see the change, not always how it combines with the rest of the system. Chained and business logic flaws still need broad or human testing.
• Noise. Frequent runs multiply findings. Without exploit confirmation before alerting, the team inherits a triage queue.
• Environment cost. Realistic staging, seeded test data and multi-tenant test accounts have to exist and stay current.
• Safety. More runs against more systems means more chances to disturb something. Rate limits, exclusions and a stop contact belong in the rules of engagement.
• Ownership. Someone has to own the trigger policy, release gates and retest queue, or the program decays into an ignored dashboard.

For the broader category that includes breach and attack simulation, see continuous security validation. For how subscriptions are sold, see penetration testing as a service.

Written by Parameter · Last reviewed September 27, 2026