A8.29 Security testing in development and acceptance

Security testing in the development and acceptance phases ensures that vulnerabilities are identified and remediated before software or systems go live. This testing should be built into the software development lifecycle (SDLC) and include various techniques like static analysis, dynamic analysis, penetration testing, and code review.

ISO 27001 A8.29 Security testing in development and acceptance emphasizes the importance of validating security controls and ensuring that systems meet defined security requirements before being released into production. Early and continuous security testing helps prevent costly post-deployment vulnerabilities and supports a proactive security posture.

Implementation Guide #

Step 1: Integrate Security Testing into SDLC

• Define where security testing fits into the SDLC stages—requirements, design, development, testing, and acceptance.
• Establish mandatory security gates before any production release.
  → Tool Recommendation: Jira, Azure DevOps, or GitLab to track security tasks and integration points.

Step 2: Perform Static Application Security Testing (SAST)

• Use automated tools to analyze source code or binaries for common vulnerabilities without executing the code.
• Perform SAST during early development stages.

→ Tool Recommendation:

• SonarQube, Checkmarx, Fortify, CodeQL

Step 3: Conduct Dynamic Application Security Testing (DAST)

• Test running applications for security issues such as injection flaws, authentication issues, or misconfigurations.
• Simulate real-world attack techniques during the testing phase.

→ Tool Recommendation:

• OWASP ZAP, Burp Suite, AppScan

Step 4: Use Software Composition Analysis (SCA)

• Identify and assess risks from third-party libraries and open-source dependencies.
• Continuously monitor for known vulnerabilities (CVEs).

→ Tool Recommendation:

• Snyk, WhiteSource, Dependabot, Black Duck

Step 5: Perform Penetration Testing During Acceptance

• Conduct manual or automated penetration tests before accepting major releases or new systems.
• Simulate real-world attack scenarios to validate the effectiveness of implemented controls.
  → Tool Recommendation: Metasploit, Nessus, Kali Linux, or engage certified ethical hackers.

Step 6: Automate Testing in CI/CD Pipelines

• Integrate SAST, DAST, and SCA tools directly into the CI/CD workflow to automate detection and remediation.
  → Tool Recommendation: GitHub Actions, GitLab CI, Jenkins, Azure Pipelines

Step 7: Maintain Testing Documentation and Logs

• Record all findings, resolutions, and acceptance criteria.
• Document evidence of re-testing and approval before production deployment.

Templates #

• Security Testing Plan Template
• SAST/DAST Scan Report Template
• Penetration Testing Report Template
• Secure Release Checklist
• Vulnerability Remediation Log

Example #

A software company deploying a new HR platform embedded security testing into their DevOps pipeline. They used SonarQube for SAST, OWASP ZAP for DAST, and Snyk for open-source risk scanning. Before the final release, an external team conducted a penetration test. All critical findings were resolved, and a final report was signed off by the security team before production deployment.

How to Comply #

To comply with ISO 27001 A.8.29, organizations should:

• Integrate security testing across all stages of development and acceptance.
• Use appropriate tools for automated and manual testing.
• Maintain documentation of test results, vulnerability remediation, and sign-offs.
• Establish criteria for acceptable risk levels before deployment.

How to Pass an Audit #

Key Documents to Prepare:

• Security Testing Strategy and Plan
• Tool Output Reports (SAST, DAST, SCA)
• Penetration Testing Reports
• Remediation and Re-testing Logs
• Deployment Approval Logs

What the Auditor Will Check:

• Is security testing consistently performed before software release?
• Are automated tools and manual testing part of the process?
• Is there documentation of vulnerabilities found and actions taken?
• Are acceptance criteria enforced with security sign-off?

Top 3 Mistakes People Make #

• Only testing for functionality—not for security—before go-live.
• Relying solely on automated tools, missing logic or business-layer vulnerabilities.
• Failing to test third-party components or APIs used within the system.

ISO 27001 Security Testing FAQ #

Q1: Is security testing required for every software change?
Not necessarily. But significant updates, new releases, and high-risk changes should trigger full security testing.

Q2: Can internal teams perform penetration testing?
Yes, if they have the appropriate skills and are independent of the development team. Third-party testing is recommended for high-impact systems.

Q3: How often should testing tools be updated?
Regularly—ideally as part of your patching and tool management strategy. Many tools also auto-update CVE databases.

ISO 27001 Controls and Attribute Values #

Thorough security testing reduces post-deployment risks and builds confidence in the security of systems released into production.