Skip to content
compliancebase
ISO 27001A.8 — Security testing in development and acceptance

A.8.29

Security testing in development and acceptance

ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026

Objective

Define and apply security testing processes in the development lifecycle.

Points of focus

  • Automated security testing (SAST, DAST, dependency scanning) runs as part of the CI/CD pipeline
  • Independent penetration testing is performed at least annually or after major architecture changes
  • Security testing scope covers the application, APIs, and infrastructure, not just the UI
  • Findings are risk-rated and tracked to closure with defined SLAs by severity
  • High-severity findings can actually block a release, not just get logged for later

Implementation notes

Layer security testing by cost and depth: automated SAST and dependency scanning on every pull request catch the cheapest classes of bugs continuously; DAST against a staging environment that mirrors production catches runtime issues automated static analysis misses; and an independent third-party penetration test, run at least annually and after any major architectural change (new authentication system, new product line, significant infrastructure migration), catches the business-logic and chained vulnerabilities that automated tools reliably miss. Keep staging environments genuinely representative of production — same authentication flow, same data model, comparable configuration — since a stale or simplified staging environment quietly defeats the value of dynamic testing. Risk-rate every finding using a consistent scale (CVSS or an internal equivalent) and set remediation SLAs by severity — commonly days for critical, weeks for high, a quarter for medium — and track them in the same ticketing system engineering already uses so remediation doesn't become a parallel, easily-ignored process. Build a real release gate: define what severity of open finding blocks a launch versus what can ship with an accepted-risk sign-off from a named owner, and enforce it consistently rather than making exceptions under deadline pressure that quietly become the norm. If you run a bug bounty or vulnerability disclosure program, feed those submissions into the same triage and tracking pipeline as internal testing rather than treating them separately, since they're often your highest-signal source of real-world findings.

Audit tip: Bring the most recent penetration test report and walk through the highest-severity finding end to end: when it was found, who owned the fix, and when it was verified closed. A single well-tracked remediation is more convincing than a clean-looking summary page.

Evidence auditors typically request:

  • Most recent third-party penetration test report with scope, findings, and remediation status
  • CI/CD pipeline configuration showing DAST or dynamic scanning against a staging environment
  • Vulnerability tracking log or ticket queue showing findings by severity with remediation dates
  • Release checklist or gate showing security sign-off required before a major launch
  • Bug bounty program policy and a sample of triaged submissions, if the company runs one

Common gaps

  • The annual penetration test report exists but critical findings from a year ago are still open with no remediation plan or compensating control
  • DAST scanning targets a staging environment that has drifted significantly from production, so it misses vulnerabilities that only exist in the live configuration
  • Security testing is treated as a compliance checkbox run once before the audit rather than a recurring part of the release process

Cross-Framework Mapping

FrameworkRequirementImplementation note
ISO 27001A.8.29This control
SOC 2CC8.1, CC7.1Related Trust Services Criteria themes — map in your crosswalk; not identical requirements.

Primary sources

Frequently Asked Questions

Annually is the common baseline, plus after any major architecture change. The exact cadence should be risk-based and documented in your testing policy rather than assumed.

Automated scanning is necessary but not sufficient — most auditors and, more importantly, most real attackers exploit business-logic flaws that only manual testing reliably finds, so an annual manual test is expected for most SaaS scopes.

No. Auditors want evidence of a working risk-based remediation process — critical findings closed quickly, lower-severity findings tracked with a documented timeline or accepted-risk rationale.

It complements but doesn't replace it — bug bounty coverage depends on what researchers choose to test, while a scoped penetration test guarantees coverage of the areas you specify, including internal or less externally visible systems.

Framework versions referenced in this page:

  • ISO/IEC 27001 — ISO/IEC 27001:2022

Last verified: July 2026 · Primary sources linked above