ISO 27001 Annex A 8.29 – Security Testing in Development and Acceptance focuses on ensuring that security testing is performed during development and before applications or systems are accepted for production use.
The objective is to identify security weaknesses before they become production security problems.
For startups and SaaS companies, this is especially important because applications are frequently updated, deployed through CI/CD pipelines, integrated with APIs, and exposed directly to customers.
What is ISO 27001 Annex A 8.29?
A.8.29 focuses on security testing during:
- Software development
- Application changes
- System development
- Integration
- Testing
- User acceptance
- Pre-production
- Major releases
Security testing should be planned and performed according to the organization’s risk and development approach.
In simple terms:
Don’t wait for customers or attackers to discover security weaknesses. Test security before the system is accepted and released.
Simple Explanation
Consider a startup developing a SaaS application.
A normal testing process may check:
- Does the login work?
- Does the customer receive an email?
- Does the report generate correctly?
- Does the API return the correct result?
Security testing asks additional questions:
- Can another user access this account?
- Can a normal user access an administrator function?
- Can an attacker bypass authentication?
- Can malicious input cause unexpected behavior?
- Are sensitive data and credentials exposed?
- Are APIs properly protected?
- Are known vulnerabilities present in dependencies?
Therefore:
Functional Testing + Security Testing = More Complete Release Validation
Why is Security Testing Important?
Security vulnerabilities can lead to:
- Unauthorized access
- Data breaches
- Account takeover
- Privilege escalation
- Information disclosure
- API abuse
- Injection attacks
- Malicious code execution
- Business disruption
- Customer impact
- Regulatory and contractual issues
Testing before production helps identify vulnerabilities while they are still easier to fix.
What Does A.8.29 Require?
Organizations should establish and perform security testing appropriate to the system and its risks.
Testing should be integrated into development and acceptance processes.
Depending on the organization, this may include:
- Security requirements testing
- Code analysis
- Vulnerability scanning
- Dependency scanning
- SAST
- DAST
- API security testing
- Configuration security testing
- Container security testing
- Infrastructure-as-Code security testing
- Penetration testing
- Manual security testing
- Authentication testing
- Authorization testing
- Access-control testing
- Security regression testing
Not every application requires every type of testing.
The testing approach should be risk-based and appropriate to the application.
Activities Required to Implement A.8.29
1. Define Security Testing Requirements
Before testing begins, determine what security needs to be tested.
Examples:
- Authentication
- Authorization
- Session management
- Input validation
- Encryption
- API security
- Access control
- Logging
- Data protection
- Configuration
- Dependencies
- Vulnerabilities
Security requirements should be connected to the application requirements defined under A.8.26.
2. Define Testing at Different SDLC Stages
Security testing should not necessarily happen only immediately before production.
A practical lifecycle is:
Development → Automated Security Testing → Integration Testing → Security Testing → Acceptance Testing → Production
Different tests can be performed at different stages.
| Stage | Example Security Activity |
|---|---|
| Development | Secure coding checks |
| Code Commit | Secret scanning |
| Build | SAST |
| Dependency Installation | SCA/dependency scanning |
| CI/CD | Container/IaC scanning |
| Test Environment | DAST |
| Pre-Production | Security assessment |
| Major Release | Penetration testing where appropriate |
| Acceptance | Security requirements validation |
| Production | Continuous monitoring |
3. Perform Static Application Security Testing
SAST analyzes source code or compiled code to identify potential vulnerabilities.
It may identify issues such as:
- Injection risks
- Unsafe functions
- Hardcoded secrets
- Weak coding patterns
- Security-sensitive coding errors
SAST can be integrated into CI/CD pipelines.
Example:
Developer → Pull Request → SAST → Result → Remediation → Merge
4. Perform Dynamic Application Security Testing
DAST tests a running application.
It can help identify issues involving:
- Authentication
- Sessions
- Input handling
- Web application vulnerabilities
- Security headers
- Access control weaknesses
DAST can be performed against an appropriate test or staging environment.
5. Perform Dependency Security Testing
Applications often use third-party libraries and open-source components.
Dependency scanning can identify known vulnerabilities.
Example:
Dependency Added → Scan → Vulnerability Found → Risk Assessment → Update → Test → Deploy
This is particularly important for modern applications with large dependency trees.
6. Test Authentication and Authorization
Security testing should verify that users can access only what they are authorized to access.
Examples:
Authentication Testing
- Invalid password
- Account lockout/rate limiting
- MFA
- Session expiration
- Password reset
- Token security
Authorization Testing
- Horizontal privilege escalation
- Vertical privilege escalation
- Tenant isolation
- Restricted administrative functions
- API authorization
For multi-tenant SaaS applications, tenant isolation testing is especially important.
7. Perform API Security Testing
APIs should be tested for:
- Authentication
- Authorization
- Input validation
- Rate limiting
- Token handling
- Data exposure
- Error handling
- Parameter manipulation
- Excessive data access
Example:
A customer should not be able to modify an API request and retrieve another customer’s information.
8. Test Security Requirements
Security requirements defined during application design should be tested.
For example:
Requirement
Administrators must use MFA.
Test
Attempt administrative access without MFA.
Expected Result
Access is denied.
Evidence
Security test result.
This creates a useful chain:
Security Requirement → Implementation → Test → Evidence
9. Perform Penetration Testing Based on Risk
Penetration testing can provide deeper security assessment for important systems.
It may be appropriate for:
- Internet-facing applications
- High-risk applications
- Major releases
- Significant architecture changes
- Applications processing sensitive information
- Customer-required assessments
Penetration testing should be performed by appropriately qualified personnel.
The organization should track findings through remediation.
10. Test Infrastructure and Configuration
Application security testing should not necessarily be limited to source code.
Depending on the environment, testing may include:
- Cloud configuration
- Network configuration
- Firewall rules
- Security groups
- Containers
- Kubernetes
- Infrastructure-as-Code
- Storage permissions
- IAM configuration
- TLS configuration
For example, a secure application can still be exposed because its cloud storage is incorrectly configured.
11. Define Vulnerability Acceptance Criteria
Not every security finding has the same risk.
The organization should define how findings are assessed.
For example:
| Severity | Example Action |
|---|---|
| Critical | Block release / immediate remediation |
| High | Remediate before release unless formally accepted |
| Medium | Track and remediate based on risk |
| Low | Track or address during normal improvement |
The exact criteria should be appropriate to the organization’s risk.
Exceptions should be documented and approved where appropriate.
12. Perform Security Regression Testing
When a vulnerability is fixed, verify that:
- The vulnerability is actually resolved.
- The fix has not introduced another security problem.
- Existing security functionality continues to work.
Example:
Vulnerability Found → Fix → Retest → Confirm Closure
Example: SaaS Startup
Consider a SaaS startup with:
- React frontend
- Node.js backend
- PostgreSQL
- AWS
- GitHub
- CI/CD pipeline
The company implements:
Every Pull Request
- Code review
- SAST
- Secret scanning
Every Build
- Dependency scanning
- Container scanning
Staging Environment
- DAST
- API security testing
Major Release
- Security regression testing
- Risk-based penetration testing
Before Production
- Critical/high-risk findings reviewed
- Security requirements verified
- Release approval completed
After Remediation
Security findings are retested before closure.
This provides a practical security testing lifecycle without requiring every test to be performed manually.
When Should Security Testing Be Triggered?
Security testing should be considered when:
- Developing a new application
- Adding major functionality
- Changing authentication
- Changing authorization
- Introducing a new API
- Adding third-party integrations
- Changing architecture
- Introducing new technology
- Changing cloud infrastructure
- Updating critical dependencies
- Discovering a vulnerability
- Fixing a security issue
- Preparing a major production release
- Introducing sensitive data
- Changing regulatory requirements
- Receiving a significant customer security requirement
- Experiencing a security incident
Startup-Focused Quick Summary
A startup does not need to run every possible security test for every release.
A practical risk-based approach is:
Every Code Change
- Code review
- Automated security checks
- Secret scanning
Regularly
- Dependency scanning
- Vulnerability scanning
- DAST where appropriate
Major Releases
- Security testing
- API testing
- Security regression testing
High-Risk Applications
- Penetration testing
- Deeper security assessment
Before Production
- Verify important security requirements
- Review critical/high-risk findings
- Obtain appropriate release approval
Minimum Startup Implementation
A practical minimum can include:
1. Secure Development Process
↓
2. Automated SAST / Security Scanning
↓
3. Dependency Scanning
↓
4. Secret Scanning
↓
5. API/Application Security Testing
↓
6. Vulnerability Management
↓
7. Pre-Production Security Review
↓
8. Risk-Based Penetration Testing
↓
9. Security Regression Testing
↓
10. Release Approval
Simple Rule
Every important application change should have an appropriate security test before it reaches production.
Example Security Testing Plan
| Test | Frequency/Trigger | Responsibility | Evidence |
|---|---|---|---|
| SAST | CI/CD | Development | Scan report |
| Secret scanning | Every code change | Development | Scan result |
| Dependency scanning | CI/CD/regular | Development/Security | SCA report |
| DAST | Releases/regular | Security/Engineering | DAST report |
| API security testing | Major API changes | Security/Engineering | Test report |
| Vulnerability scanning | Regularly | Security/IT | Scan report |
| Penetration testing | Risk-based | Security/External Tester | Pentest report |
| Regression testing | After security fixes | QA/Security | Retest result |
| Security acceptance | Before major release | Product/Security | Approval record |
Example Security Test Register
| Application | Test Type | Date | Findings | Risk | Status | Evidence |
|---|---|---|---|---|---|---|
| Customer Portal | SAST | 2026-09 | 2 | Medium | Closed | Report |
| Customer Portal | DAST | 2026-09 | 1 | Low | Open | Report |
| API Platform | API Security | 2026-08 | 3 | High | Closed | Test Report |
| Mobile App | Pentest | 2026-07 | 4 | Medium | Closed | Pentest Report |
What Evidence Can an Auditor Ask For?
An auditor may review:
- Security testing policy/procedure
- SDLC procedure
- Security testing plan
- Security requirements
- SAST reports
- DAST reports
- Dependency scan reports
- Secret scan results
- Container scans
- IaC security scans
- Vulnerability scan reports
- Penetration testing reports
- API security testing
- Security regression testing
- Test cases
- Test results
- Vulnerability register
- Remediation tickets
- Retesting evidence
- Release approvals
- Security acceptance records
- Exception/risk acceptance records
The auditor is generally looking for evidence that security testing is planned, performed, reviewed, and followed by appropriate action.
ISO 27001 A.8.29 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Is security testing included in the development process? | SDLC procedure |
| Are security testing requirements defined? | Testing standard |
| Is testing performed during development? | SAST/scan results |
| Is security testing performed before acceptance/release? | Test reports |
| Are application vulnerabilities identified? | Scan reports |
| Are dependencies tested? | SCA reports |
| Are APIs tested? | API security test |
| Are authentication and authorization tested? | Test cases/results |
| Are high-risk applications subject to deeper testing? | Risk assessment/pentest |
| Are vulnerabilities tracked? | Vulnerability register |
| Are findings remediated? | Tickets |
| Are fixes retested? | Retest evidence |
| Are security requirements validated? | Acceptance testing |
| Are security exceptions documented? | Risk acceptance |
| Are test results retained? | Test records |
| Is the testing approach reviewed when systems change? | Review/change records |
Common Mistakes
1. Testing Only Functionality
A system can work perfectly from a functional perspective while still being vulnerable.
Better approach:
Functional Testing + Security Testing
2. Performing One Annual Penetration Test and Calling It Done
Penetration testing can be valuable, but it does not replace continuous or lifecycle-based security testing.
Applications change throughout the year.
Better approach: combine automated and manual testing appropriate to risk.
3. Testing Only Before Production
Finding vulnerabilities at the final stage can delay releases and increase remediation costs.
Better approach: integrate testing into development and CI/CD.
4. Ignoring APIs
Modern applications often expose significant functionality through APIs.
Better approach: include API security testing where applicable.
5. Not Retesting Fixed Vulnerabilities
A ticket marked “resolved” does not necessarily demonstrate that the vulnerability has actually been fixed.
Better approach:
Fix → Retest → Verify → Close
6. No Risk-Based Approach
Testing every application with the same depth can waste resources.
Better approach: increase testing depth according to application risk, exposure, sensitivity, and business impact.
7. Keeping No Evidence
A company may perform security testing but fail to retain evidence.
Better approach: maintain reports, scan results, tickets, approvals, and retest records.
Practical Implementation Model
A.8.29 can be implemented using:
Identify Security Requirements
↓
Define Testing Strategy
↓
Select Appropriate Tests
↓
Integrate Automated Testing
↓
Perform Manual/Specialized Testing
↓
Identify Findings
↓
Assess Risk
↓
Remediate
↓
Retest
↓
Security Acceptance
↓
Release
↓
Monitor & Improve
Policy vs Test vs Finding vs Evidence
| Layer | Example |
|---|---|
| Policy | Application Security Testing Policy |
| Requirement | API must enforce authorization |
| Test | Attempt unauthorized API access |
| Finding | Authorization bypass identified |
| Remediation | Code/configuration corrected |
| Retest | Unauthorized request blocked |
| Evidence | Test report + ticket + retest result |
This distinction is important for ISO 27001 audits.
A policy saying “applications are security tested” is not enough.
The organization should demonstrate that testing actually occurred and identified issues were appropriately addressed.
A.8.25 vs A.8.26 vs A.8.27 vs A.8.28 vs A.8.29
These controls work together:
| Control | Main Question |
|---|---|
| A.8.25 – Secure Development Life Cycle | How is security integrated into development? |
| A.8.26 – Application Security Requirements | What security does the application need? |
| A.8.27 – Secure System Architecture & Engineering Principles | How should the system be designed securely? |
| A.8.28 – Secure Coding | How should developers write secure code? |
| A.8.29 – Security Testing in Development & Acceptance | How do we verify that security requirements and controls work? |
A simple lifecycle is:
A.8.26 → Define Requirements
↓
A.8.27 → Design Securely
↓
A.8.28 → Develop Securely
↓
A.8.29 → Test Security
↓
A.8.25 → Manage Security Throughout the SDLC
Useful Resources
Draft Application Security Testing Policy
[Insert Draft Application Security Testing Policy Link]
Security Testing Checklist
[Insert Security Testing Checklist Link]
Application Security Test Plan
[Insert Application Security Test Plan Link]
API Security Testing Checklist
[Insert API Security Testing Checklist Link]
Vulnerability Management Register
[Insert Vulnerability Management Register Link]
Security Release Checklist
[Insert Security Release Checklist Link]
Penetration Testing Checklist
[Insert Penetration Testing Checklist Link]
Related ISO 27001 Controls
A.8.29 works closely with:
- A.5.8 – Information security in project management
- A.5.15 – Access control
- A.5.23 – Information security for use of cloud services
- A.8.4 – Access to source code
- A.8.8 – Management of technical vulnerabilities
- A.8.9 – Configuration management
- A.8.24 – Use of cryptography
- A.8.25 – Secure development life cycle
- A.8.26 – Application security requirements
- A.8.27 – Secure system architecture and engineering principles
- A.8.28 – Secure coding
- A.8.31 – Separation of development, test and production environments
- A.8.32 – Change management
Final Takeaway
ISO 27001 Annex A 8.29 is about making security testing a normal part of development and acceptance, rather than treating it as an optional activity after deployment.
For startups, a practical approach is:
Define security requirements → Test throughout development → Identify vulnerabilities → Remediate → Retest → Approve → Release
The goal is not to perform every possible security test on every application.
The goal is to ensure that security testing is appropriate to the application’s risk and is performed before important systems or changes are accepted into production.