--- title: "Scheduling & Continuous Security" description: "Set up recurring pentests to maintain continuous visibility into your security posture, track trends over time, and ensure new vulnerabilities are caught automatically." canonical: https://turbopentest.com/learn/integration-automation/scheduling source: "TurboPentest Learn" --- # 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 ``` ```json { "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 `continuityStatus` relative to the previous pentest. TurboPentest uses three values: - **new** - First time this vulnerability has been observed (not present in the prior pentest) - **confirmed** - The vulnerability matched a finding from the previous pentest by fingerprint - **retest_confirmed** - A prior finding that this run's live retest actively re-verified as still present The `retest_confirmed` status comes from a **live fresh-oracle retest that runs inside Phase 2** (not a stored comparison). For each prior finding, the retest oracle returns a verdict of `still_present`, `fixed`, or `unsure`, which maps to confirmed, not_confirmed, or unsure. Findings the retest verifies as fixed are recorded as not confirmed (resolved) rather than presented as active. 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.