Continuous penetration testing
always-on, not once-a-year
Run penetration testing as an always-on programme rather than an annual project. Schedule recurring scans, deliver findings live in a branded client portal, pair retests to original findings, and keep the engagement record open between assessment windows so coverage is continuous and the audit trail is complete.
No credit card required. Free plan available forever.
Continuous penetration testing for security teams and consultancies
The annual penetration test cycle was designed for systems that changed once a quarter and shipped once a year. That world is gone. Modern products release multiple times a week, infrastructure rebuilds itself in a CI pipeline, and new assets appear without a procurement cycle around them. Treating penetration testing as a once-a-year project on top of that pace is how coverage drift becomes the real risk: the report is accurate the day it lands and stale a month later. Continuous penetration testing closes that gap by running pentest delivery as an ongoing programme, with scheduled scans on a real cadence, manual testing layered on top, and a live engagement record that persists between assessment windows.
This page is the workflow view. For the buyer-facing argument behind subscription delivery, see the longer-form penetration testing as a service guide. For the economic logic behind day rate, fixed fee, retainer, and PTaaS subscription pricing, read the research on pentest pricing models and the analysis of the pentest delivery gap.
What a continuous penetration testing programme actually does
Recurring engagement record
A continuous engagement persists between assessment windows rather than closing at the end of each cycle. Scope, rules of engagement, owners, and aging findings carry forward, so the next scan starts from the current state instead of a blank slate.
Scheduled scans on a real cadence
Run weekly, monthly, or release-triggered external and authenticated scans against in-scope assets. The cadence is configured per asset class so a fast-moving SaaS app gets tested every release while a stable infrastructure perimeter gets a monthly sweep.
Live findings in the client portal
Findings publish to the branded client portal as soon as triage is complete rather than waiting for the next report cycle. Stakeholders see the current risk picture, not a snapshot from six weeks ago.
SLA-driven remediation across cycles
Each finding gets an owner, a severity-based SLA, and a status workflow that tracks open through verified close. Aging counters keep overdue items visible across multiple assessment windows so nothing quietly drifts.
Retest pairing
Pair each retest to the original finding so the close-out carries the original scope, the fix, the retest evidence, and the outcome on a single record. Regression handling reopens findings automatically when a previously closed issue reappears in a later scan.
Continuous attack surface coverage
Subdomain, cloud, and exposed-service discovery runs on the same cadence as the scans, so newly launched assets enter the testing programme without a separate procurement cycle. Coverage drift is the failure mode continuous testing is meant to prevent.
Project-based pentesting versus continuous penetration testing
Both models have a place. The right choice depends on the workload, not the brand. The comparison below is a practical view of where each model fits, drawn from the operational differences rather than the marketing copy.
Project-based pentesting
- A single, scoped engagement with a defined start and end date.
- A static report at the end. Findings age out as soon as the report lands.
- Retests scoped and quoted as a separate engagement, often months later.
- Best fit for: compliance-driven point-in-time assessments and well-bounded one-off scopes.
Continuous penetration testing
- A recurring engagement that persists across assessment windows.
- A live portal. Findings, retests, and reports update on the actual cadence of the work.
- Retests inside the programme, paired to original findings. Closure data is the deliverable.
- Best fit for: fast-moving products, regulated environments with monthly or quarterly testing, and security programmes where coverage drift is the real failure mode.
A sensible default cadence by asset class
Continuous does not mean every check on every asset every day. Cadence is calibrated to change rate, exposure, and risk. The default ladder below is a starting point that holds up across most programmes; tune the rows to your release cadence and document the choice on the engagement record so the cadence is auditable rather than implicit.
| Asset class | Default cadence | Why |
|---|---|---|
| Customer-facing web app or API (fast release) | Per release (CI-triggered) plus weekly authenticated scan | Authenticated DAST and SAST run on every merge. A weekly authenticated DAST sweeps logged-in flows the per-merge scan does not cover. |
| Customer-facing web app (steady release) | Weekly authenticated scan plus monthly external scan | Weekly authenticated scans pick up regressions; monthly external scans catch perimeter changes such as new subdomains or exposed services. |
| Internal corporate web app | Monthly authenticated scan | Lower change rate and lower exposure, but still inside the trust boundary. Monthly cadence is enough to catch configuration drift. |
| External infrastructure (perimeter) | Weekly external scan | Subdomain enumeration, cloud bucket exposure, and SSL or DNS misconfigurations move on the timescale of a release cycle, not a quarter. |
| Code repositories (SAST and SCA) | Per merge plus weekly scheduled run | Per-merge SAST catches new code; weekly SCA picks up newly published CVEs against existing dependencies that did not change. |
| Manual application pentest | Quarterly or per major release | Manual testers find business logic and chained issues automation cannot. The continuous programme funds the cadence; the human cycle layers on top of the automated baseline. |
The continuous penetration testing pipeline
The pipeline below is the operational shape of a continuous engagement. Each step is timestamped, each handoff is auditable, and the engagement record carries the full history across cycles rather than resetting after each report.
- A recurring engagement is created with scope, target assets, rules of engagement, the testing cadence, and the severity-driven SLA tiers documented on the engagement record itself.
- Scheduled external, authenticated, and code scans run on the configured cadence, with results flowing into the same engagement as any manual pentest findings.
- Each finding is auto-scored with a CVSS 3.1 vector, deduplicated against existing open findings, and assigned an owner and an SLA before it surfaces in the client portal.
- The branded client portal carries the live picture: open findings by severity, overdue counters, recent retests, and the trend across the last few assessment windows.
- Owners work fixes inside the finding record, attach evidence, and request a retest. The retest is paired to the original finding so the close-out is self-documenting.
- When a closed finding reappears in a later scan, the platform reopens it with regression notes attached, so the close, regression, and re-close history stays on a single record.
- AI generates an executive summary, a technical report, or a remediation roadmap on demand from the live data, so a quarterly report or a board update is a snapshot of an active programme rather than a one-off project artefact.
For pentest firms and security consultancies
Continuous penetration testing is the operational shape that turns a project pipeline into a renewable programme. Pentest firms running multiple engagements per month, and security consultants building durable client relationships, both benefit from a delivery model that produces a live record per client rather than a stack of frozen PDFs. The platform-side mechanics also remove the coordination overhead that erodes margin under any pricing model.
A retainer that bills outcomes, not hours
Continuous engagements turn pentest delivery into a programme buyers can renew without re-procuring every quarter. The recurring scope, the live portal, and the closure data become the renewal argument, not a sales conversation.
Retests inside the headline price
Continuous engagements make retests a low-friction part of the workflow rather than a separate quote. Pricing the retest into the programme aligns the contract with verified closure rather than discovered findings.
Cross-engagement coverage as a deliverable
A continuous engagement gives the consultancy a defensible answer to coverage questions. The recurring scan history, the manual cycle on top, and the closure data are the answer, and they sit on a single record.
Faster onboarding of new assets
New assets join the continuous engagement as scope changes rather than triggering a new project from scratch. Onboarding goes from a procurement cycle to a configuration change.
For internal security teams and AppSec
Internal teams running an application security programme face a different version of the same problem. Findings come from third-party pentests, scanner output, and internal reviews, each on a different cadence, and engineering wants tickets in their own tool. A continuous engagement record fixes the drift by holding the finding-side state (severity, owner, SLA, retest, closure) in one place while engineering keeps working in their issue tracker. Auditors get the same export every cycle and risk gets a real picture of coverage rather than a quarterly snapshot.
Live coverage answers for risk and audit
A continuous programme gives risk and audit a single view: what is in scope, what is being tested, what is open, and what was closed. The same view answers SOC 2, ISO 27001, NIST CSF, and PCI DSS coverage questions without rebuilding the picture each time.
Aging findings stay visible
In project-based pentesting, mediums and lows quietly age out of the report cycle. A continuous engagement carries them across cycles with the SLA clock running, so the long tail stops disappearing.
Engineering planning gets real numbers
Closure timestamps and SLA performance over multiple cycles give engineering and security real numbers to plan against. The next sprint, the next hardening pass, and the next release have data, not anecdotes, behind them.
Where continuous penetration testing fails
The model is not magic and it is not free. Three failure modes show up consistently in programmes that were set up too quickly.
Cadence without depth
Running a weekly automated scan and calling it continuous pentesting misses the manual layer that finds business logic and chained issues. Continuous is the cadence of the programme, not a replacement for human-led testing.
Findings without owners
Live findings without owners and SLAs become an alert fatigue problem inside a quarter. Continuous coverage only works when the remediation workflow is built into the same record as the scan output.
Scope without governance
New assets appearing in scope without a documented change procedure produce unauthorised testing risk and audit gaps. Continuous engagements need scope changes logged on the engagement record, not negotiated over email.
How continuous pentesting connects to the rest of the platform
Continuous penetration testing sits on top of engagement management for the recurring scope and team assignment, uses continuous monitoring for the scheduled scan cadence, depends on findings management for CVSS scoring, templates, and scanner imports, runs the remediation side through the remediation tracking workflow, and uses AI reports to produce snapshots on demand from the live data. The wider project structure of an engagement (scope, team, retests, invoicing) is captured in the pentest project management workflow, which the continuous model layers on top of rather than replaces.
Compliance-ready by default
Continuous coverage maps directly to SOC 2 CC7, ISO 27001 A.12, NIST CSF Detect, PCI DSS Requirement 11, and the testing clauses in NIS2, DORA, and HIPAA. The export per engagement is the audit artefact, not a separate report you assemble after the fact.
Built for delivery, not vanity
The portal is the deliverable. The report is a snapshot of an active programme. The retest is a routine part of the workflow. Coordination overhead drops because the workflow is the system of record rather than a layer on top of email and PDFs.
Continuous penetration testing is not a brand or a price book. It is a delivery model that aligns the cadence of testing with the cadence of change in the systems being tested. Done well, it removes the structural coverage drift that point-in-time testing cannot fix. Done badly, it becomes a weekly automated scan with no remediation pipeline attached. The difference is the workflow, the engagement record, and the discipline around scope, ownership, SLAs, and retests. SecPortal is built for the workflow, so the continuous part of the programme is operationally cheap to run and commercially defensible to sell.
If you are evaluating whether to run continuous testing yourself or buy it as a marketplace service, the SecPortal vs Cobalt comparison covers the trade-off between PTaaS and a pentest delivery platform you run with your own testers. For the commercial layer that sits above continuous delivery, the pentest retainer management workflow covers contracted hours, drawdown tracking, billing cadence, and the renewal evidence the record carries by default.
Frequently asked questions about continuous penetration testing
What is continuous penetration testing?
Continuous penetration testing is a delivery model where penetration testing runs as an ongoing programme rather than a single project. Scheduled scans run on a defined cadence, manual testing layers on top at agreed intervals, findings publish to a live portal as they are triaged, and retests pair to the original finding when the fix is verified. The engagement record persists across assessment windows, so coverage is continuous and aging findings stay visible until they are closed.
How is continuous penetration testing different from PTaaS?
Continuous penetration testing is the delivery model. PTaaS (penetration testing as a service) is a commercial wrapper around it that bills as a subscription instead of per project. The two terms are often used interchangeably, but a programme can be continuous without being subscription-priced (for example, a large retainer with scheduled cycles), and a PTaaS contract that delivers a single annual report is not really continuous in workflow terms.
When does continuous penetration testing make economic sense?
Continuous penetration testing makes sense when the buyer needs ongoing coverage rather than a point-in-time assessment. Fast-moving SaaS products, regulated environments with monthly or quarterly testing obligations, and programmes where retests and incremental scope changes are routine all fit. For a single annual engagement against a stable scope, a project-based fixed fee is usually more efficient. The economics flip in three places at once: retests become free at the margin, scoping becomes incremental, and reporting becomes continuous.
Does continuous penetration testing replace manual pentesting?
No. Continuous penetration testing combines automated scanning on a real cadence with periodic manual testing on top. Automation catches regressions, configuration drift, and known-vulnerability exposure between manual cycles. Manual testers find business logic flaws, chained issues, and complex authorisation problems that automation cannot. The continuous part is the cadence and the workflow; the manual part still happens, just on a programme cadence rather than as a one-off.
How should retests work in a continuous engagement?
Retests should be inside the headline price of the continuous engagement, with each retest paired to the original finding so the close-out captures the original scope, the fix, the retest evidence, and the final outcome. Treating retests as separate quotes creates a procurement penalty for verifying remediation, which structurally underdelivers on closure. The continuous model removes that friction by making the retest a routine part of the workflow rather than a fresh engagement.
What does SecPortal provide for continuous penetration testing?
SecPortal carries continuous engagements end to end: a recurring engagement record, scheduled external and authenticated scans, code scanning on a per-merge or scheduled cadence, findings management with CVSS 3.1 and 300+ remediation templates, owner assignment and SLA tracking, retest pairing, regression handling, AI-generated reports on demand, and a branded client portal that stays open between assessment windows. The same record holds the entire programme from the first cycle to the latest one.
How do scheduled scans fit into a continuous pentest programme?
Scheduled scans give the programme its baseline rhythm. External scans run weekly to catch perimeter drift, authenticated scans run weekly or per-release to catch regressions in logged-in flows, and code scans run on every merge with a weekly scheduled top-up for new CVEs. Manual testing cycles layer on top at the agreed cadence. The scheduled scans publish into the same engagement as the manual findings, so the buyer sees one programme rather than parallel tools.
How it works in SecPortal
A streamlined workflow from start to finish.
Set up the continuous engagement
Create a recurring engagement that lives across assessment windows rather than closing after one report. Capture scope, rules of engagement, target assets, agreed cadence, and the SLA tiers that govern remediation. The engagement record carries the same identity from the first scan to the next, so findings, retests, and reports all attach to one continuous timeline.
Schedule recurring and triggered scans
Configure scheduled external and authenticated scans on the cadence the programme requires (weekly, monthly, or per-release) and trigger ad-hoc scans when scope changes or a new asset goes live. Scanner findings flow into the same engagement as manual pentest findings, so the continuous and the human-led work share one record rather than living in parallel tools.
Triage, prioritise, and assign owners live
Findings appear with auto-calculated CVSS 3.1 vectors and 300+ remediation templates from day one, so triage is fast and consistent. Assign an owner per finding, set the SLA by severity, and publish to the branded client portal as soon as triage is complete. Stakeholders see the live picture rather than waiting for the next report cycle.
Track remediation in the branded portal
Clients update fix status, ask clarifying questions, and attach evidence inside the finding record itself. No email chains, no PDF version drift. The portal stays open between assessment windows so remediation conversations carry across cycles and aging findings stay visible until they are closed.
Retest, verify, and report continuously
Pair each retest to the original finding so the close-out captures the original scope, the fix, the retest evidence, and the final outcome. AI generates executive summaries, technical reports, and remediation roadmaps on demand from the live data, so the report becomes a snapshot of a continuous programme rather than a frozen artefact.
Features that power this workflow
Run pentests as a continuous programme
Scheduled scans, live findings, retests, and reports in one always-on workflow. Start free.
No credit card required. Free plan available forever.