Scheduling & Continuous Security

Why Scheduled Pentesting Matters

Security is not a one-time event. Your application changes with every deployment. New dependencies are added. Configurations drift. Third-party services update their APIs. A target that was secure last month may have new vulnerabilities today - not because you introduced them, but because the threat landscape evolves.

Scheduled pentesting provides continuous security assurance by running pentests at regular intervals, independent of your deployment pipeline. While CI/CD integration catches vulnerabilities introduced by code changes, scheduling catches vulnerabilities introduced by environmental changes, dependency updates, and newly disclosed CVEs.

Configuring Scheduled Pentests

TurboPentest's scheduling feature lets you define one-off or recurring pentests with control over timing and tier.

Creating a Schedule

Navigate to Schedules in the TurboPentest dashboard, or use the API:

POST /api/schedules

{
  "targetFqdn": "example.com",
  "tier": "standard",
  "frequency": "weekly",
  "nextRunAt": "2026-06-15T02:00:00Z"
}

Request fields:

• targetFqdn or targetId (required) - The target to pentest. The domain must already be verified in your account.
• nextRunAt (required) - ISO 8601 timestamp for the first (or only) run.
• frequency (optional) - daily, weekly, biweekly, monthly, or quarterly. Omit it to create a one-off schedule that runs once and then completes.
• tier (optional) - recon, standard, deep, or blitz. Defaults to standard.

A scheduler job checks for due schedules every few minutes and launches each one through the normal pentest pipeline. After a recurring run, nextRunAt advances by the configured frequency; a one-off schedule is marked completed.

Schedule pentests during low-traffic hours to minimize any impact on your application.

Recommended Cadences

Different targets warrant different frequencies:

Weekly (production web applications): Your primary customer-facing applications should be pentested weekly. This catches newly disclosed vulnerabilities, configuration drift, and dependency updates.

Daily (staging/pre-production): If your team deploys frequently, daily pentests of staging ensure issues are caught before they reach production.

Monthly (internal tools): Lower-risk internal applications can be pentested monthly unless they process sensitive data.

Bi-weekly (APIs and microservices): API surfaces that change frequently benefit from bi-weekly pentests to catch breaking security changes.

Tier Selection for Schedules

Not every scheduled pentest needs to be the most thorough tier. A balanced approach:

• Weekly runs: standard tier - good coverage at reasonable cost
• Monthly deep dive: deep tier - comprehensive analysis once a month
• Post-incident: blitz tier - maximum coverage after a security event
• Daily monitoring: recon tier - fast surface-level checks for major regressions

How Schedules Consume Credits

Each scheduled run consumes one available credit matching the schedule's tier (oldest first). If no matching credit is available when the schedule fires, that run is skipped, you receive an email notification, and the schedule advances to its next run time - it is not paused or deleted. Keep enough credits of the right tier on hand (an annual subscription delivers all of its credits upfront, which pairs well with schedules).

If a pentest is still running on the target when the schedule fires, the launch is held and retried automatically once the active pentest finishes - TurboPentest never runs two pentests against the same target at once.

Finding Continuity Across Scheduled Pentests

The real power of scheduling emerges through finding continuity tracking. When pentests run against the same target repeatedly, TurboPentest automatically compares results to previous runs using vulnerability fingerprinting.

Status Tracking

Each finding carries a continuity status relative to the previous pentest:

• New - First time this vulnerability has been observed
• Confirmed - The vulnerability was found in the previous pentest and was re-detected in this run
• Persistent - The vulnerability was found previously and is carried forward as unresolved
• Fixed - The vulnerability was present previously but is confirmed resolved

A regression - a vulnerability that was previously fixed but has reappeared - shows up as a new finding in a later run. Regressions deserve immediate review because they often indicate a reverted fix or a configuration change that re-exposed an old issue.

Trend Metrics

Repeat pentests against the same target let you track security posture over time:

• Finding count over time - Is your total vulnerability count trending up or down?
• Mean time to remediate (MTTR) - How long does it take your team to fix findings, broken down by severity?
• Fix rate - What percentage of findings are resolved between consecutive pentests?
• Regression rate - How often do fixed vulnerabilities reappear?

These metrics are valuable for demonstrating security posture improvement to stakeholders and auditors.

Compliance Alignment

Many compliance frameworks require evidence of continuous security testing:

• SOC 2 - Demonstrate ongoing vulnerability management and remediation
• ISO 27001 - Show regular security assessments with tracked improvements
• PCI DSS - Quarterly external and internal vulnerability scans
• HIPAA - Regular technical vulnerability assessment

Scheduled pentests with finding continuity tracking produce reports built to meet the requirements of these frameworks, and each run's report can be exported as a PDF for audit submissions.

Managing Schedules

Pausing and Resuming

Schedules can be paused without deletion (set status to paused via PATCH /api/schedules/{id} or the dashboard). This is useful during:

• Major infrastructure migrations
• Planned downtime windows
• Credit conservation periods

Paused schedules retain their configuration and history. Resume at any time (set status back to active) to continue the cadence. You can also update a schedule's frequency, tier, and nextRunAt, or delete it entirely.

Best Practices

Start with weekly standard runs. This provides a good baseline for continuity tracking without excessive cost. Adjust frequency and tier based on your risk profile.

Schedule during off-peak hours. Run pentests when traffic is lowest to minimize any application impact.

Monitor MTTR trends. Mean time to remediate is the most actionable metric from scheduled pentesting. Set team goals to reduce it.

Keep credits stocked. Scheduled runs are skipped (with an email notification) when no matching-tier credit is available, so top up before you run out.

Review regressions immediately. A previously fixed vulnerability reappearing often indicates a deployment that reverted a fix or a configuration change that re-exposed an old issue.