Security Testing Plan: Template and Best Practices

21 Sep 2026 — 5 min read

A security testing plan documents what security testing you'll do, when, how, and with what tools. Without a plan, security testing is ad hoc—some things get tested, others don't, and nobody knows what was actually covered. A good plan defines scope, testing types for each phase of the SDLC, entry/exit criteria, tool selection, and who is responsible for what. This becomes your compliance evidence when auditors ask "how do you ensure your software is secure?"

Key Takeaways

A security testing plan is a compliance artifact, not just a project plan. SOC 2, PCI DSS, and ISO 27001 all require documented security testing practices. Your plan is the evidence.

Map testing types to SDLC phases. SAST in CI/CD, DAST in staging, penetration testing pre-release. Don't run DAST in production without explicit authorization.

Define entry and exit criteria for each test type. Entry criteria: what must be true before testing starts. Exit criteria: what must be true before the test is considered complete. Without these, testing never formally "finishes."

Classify your application before choosing tools. A simple internal CRUD app and a payment processing system require different security testing depth. Apply effort proportional to risk.

Frequency matters as much as coverage. A pentest done once three years ago provides no current assurance. Define testing frequency: SAST on every commit, DAST weekly against staging, pentest annually (or before major releases).

Plan Structure

1. Scope and Classification

Define what you're testing and how sensitive it is:

Application: Customer Portal (app.example.com)
Data Classification: Confidential (personal data, payment info)
Compliance Requirements: PCI DSS SAQ A-EP, GDPR
Threat Model: External internet-facing, authenticated users, admin portal

Risk Classification:

Tier	Description	Testing Frequency	Pentest Required
Critical	Payment processing, authentication, PII storage	Weekly DAST, annual pentest	Yes, annually
High	Internal APIs, admin interfaces, data export	Bi-weekly DAST, annual pentest	Yes, annually
Medium	Informational endpoints, public content	Monthly DAST	Recommended
Low	Static sites, internal tools	Quarterly SAST	Optional

2. Testing Types and Schedule

SDLC Phase     │ Activity                    │ Tool              │ Frequency
───────────────┼─────────────────────────────┼───────────────────┼──────────
Development    │ SAST (static analysis)      │ Semgrep/CodeQL    │ Every commit
               │ SCA (dependency scan)       │ Grype/Snyk        │ Every commit
               │ Secrets scanning            │ Gitleaks/TruffleHog│ Every commit
               │                             │                   │
Code Review    │ Security code review        │ Manual            │ Every PR
               │ SAST confirmation           │ Semgrep           │ Every PR
               │                             │                   │
Staging        │ DAST (dynamic analysis)     │ OWASP ZAP         │ Weekly
               │ IAST (with test suite)      │ Contrast Security │ Weekly
               │ API security testing        │ Burp Suite/ZAP    │ Weekly
               │                             │                   │
Pre-Release    │ Penetration testing         │ External firm     │ Annually (or major releases)
               │ Configuration review        │ Manual + tools    │ Pre-release
               │ Dependency vulnerability    │ Snyk/Grype        │ Pre-release
               │                             │                   │
Production     │ Vulnerability monitoring    │ Dependabot        │ Continuous
               │ Runtime security monitoring │ Falco/RASP        │ Continuous
               │ Log monitoring              │ SIEM              │ Continuous

3. SAST Configuration

# .semgrep.yml — Security ruleset
rules-of-engagement:
  rulesets:
    - p/owasp-top-ten
    - p/secrets
    - p/sql-injection
    - p/xss
  severity-threshold: WARNING  # Fail on ERROR and WARNING
  baseline-mode: true          # Only new findings in PRs
  exclude:
    - tests/
    - migrations/
    - "**/*.test.js"

entry-criteria:
  - Source code in version control
  - CI pipeline configured

exit-criteria:
  - Zero new CRITICAL or HIGH findings vs baseline
  - All suppressions documented with justification
  - Coverage: all source files in scan scope

4. SCA Configuration

sca-policy:
  tool: grype
  fail-on-severity: high

  vulnerability-management:
    critical:
      sla: 24 hours
      action: block-merge
    high:
      sla: 2 weeks (next sprint)
      action: block-merge, create-ticket
    medium:
      sla: 1 month
      action: create-ticket
    low:
      sla: quarterly cleanup
      action: log-only

  license-compliance:
    prohibited-licenses:
      - GPL-3.0  # Copyleft incompatible with proprietary software
      - AGPL-3.0
    review-required:
      - LGPL-2.0
      - LGPL-3.0

5. DAST Configuration

dast-policy:
  tool: owasp-zap
  target-environment: staging
  not-allowed-in: production

  scan-profiles:
    - name: API Security Scan
      type: api
      openapi-spec: https://staging.example.com/api/openapi.json
      authentication:
        method: bearer-token
        credentials-secret: DAST_API_TOKEN

    - name: Web App Scan
      type: full-crawl
      target: https://staging.example.com
      authentication:
        method: form-login
        login-url: /login
        credentials-secret: DAST_USER_CREDENTIALS

  alert-thresholds:
    fail-on-risk: High  # Fail CI if High or Critical finding

  schedule: weekly (Sundays 02:00 UTC)

  entry-criteria:
    - Staging environment running latest build
    - All functional tests passing in staging

  exit-criteria:
    - Full crawl completed (no timeout)
    - Zero High/Critical new findings vs last week
    - Report generated and stored in artifacts

6. Penetration Testing Plan

pentest-policy:
  frequency: annually
  provider: external-firm  # or: internal red team
  scope:
    in-scope:
      - External network perimeter
      - Web applications (all production)
      - API endpoints
      - Authentication systems
    out-of-scope:
      - Third-party hosted systems
      - Partners' systems
      - Production data mutation
  type: grey-box  # Provide API docs, user accounts
  duration: 2 weeks

  pre-engagement-requirements:
    - Signed Rules of Engagement
    - Emergency contact list
    - Backup/snapshot of systems before testing

  deliverables:
    - Executive summary
    - Technical findings report (CVSS scored)
    - Evidence artifacts
    - Remediation guidance
    - Retest within 60 days of patch deployment

  entry-criteria:
    - Rules of Engagement signed
    - Scope confirmed in writing
    - Test accounts provisioned
    - Emergency contact confirmed

  exit-criteria:
    - All agreed scope tested
    - Report delivered
    - Finding severity confirmed with client
    - Retest scheduled

7. Secrets Scanning

secrets-scanning:
  tool: gitleaks
  scope: git-history  # Scan entire git history, not just current state

  .gitleaksignore:
    - # Test fixtures with fake API keys
    - tests/fixtures/mock-api-keys.js

  pre-commit-hook:
    enabled: true
    action: block-commit-on-finding

  ci-integration:
    action: fail-pipeline
    notify: security-team@example.com

  rotation-policy:
    if-secret-found-in-history:
      - Rotate the secret immediately
      - Remove from git history (git-filter-repo)
      - Audit access logs for the exposed secret
      - Document incident

8. Roles and Responsibilities

Activity	Responsible	Accountable	Consulted	Informed
SAST configuration	DevSecOps	Dev Lead	Security Team	All engineers
SAST finding triage	Developer	Dev Lead	Security Team	—
DAST execution	DevSecOps	Security Lead	—	Dev Lead
DAST finding triage	Security Lead	CISO	Dev Lead	—
Pentest coordination	Security Lead	CISO	Legal, Dev Lead	Board
Vulnerability remediation	Developer	Dev Lead	Security Lead	CISO
Security plan review	Security Lead	CISO	Legal, Compliance	—

9. Compliance Mapping

Map your testing activities to compliance requirements:

Requirement	Standard	Testing Activity	Evidence
Regular vulnerability assessment	PCI DSS 11.3	Quarterly DAST scans	ZAP reports
Penetration testing	PCI DSS 11.3.1	Annual external pentest	Pentest report
Source code review	SOC 2 CC8.1	SAST on every PR	SAST pipeline logs
Change management testing	SOC 2 CC8.1	Pre-release security review	Review records
Third-party component risk	SOC 2 CC9.2	SCA weekly	Grype reports
Vulnerability management	ISO 27001 A.12.6.1	SLA-bound remediation process	Ticket records

10. Metrics and Reporting

Track these monthly and include in security reports:

Security Testing Metrics

Coverage:
  - % of repos with SAST enabled: target 100%
  - % of staging deployments with DAST scan: target 100%
  - Days since last pentest: target < 365

Vulnerability Management:
  - Open Critical findings: target 0
  - Open High findings: target < 5
  - Mean time to remediate Critical: target < 24 hours
  - Mean time to remediate High: target < 14 days
  - False positive rate (SAST): track monthly, target < 30%

Trend:
  - New vulnerabilities found this month (by severity)
  - Vulnerabilities closed this month
  - Vulnerabilities aging past SLA

Summary

A security testing plan transforms ad hoc security testing into a documented, measurable program. The critical elements:

Scope and risk classification — know what you're protecting
Testing by SDLC phase — SAST/SCA in CI, DAST in staging, pentest pre-release
Entry and exit criteria — testing formally starts and ends
SLAs for remediation — Critical in 24h, High in 2 weeks
Compliance mapping — know which tests satisfy which requirements
Metrics — measure coverage, velocity, and trend

The plan isn't a guarantee of security—it's a guarantee that security is treated as a repeatable engineering discipline rather than a one-time checkbox.