In this guide you will learn how to implement ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.
ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance is an ISO 27001 control that requires an organisation to test software before they put it into production to ensure that information security requirements have been met.
Table of contents
- Key Takeaways
- Purpose & Definition
- ISO 27001 Annex A 8.29 Requirements and Guidance
- How to implement ISO 27001 Annex A 8.29
- ISO 27001 Annex A 8.29 Implementation Checklist
- ISO 27001 Toolkit
- ISO 27001 Annex A 8.29 Audit Checklist
- ISO 27001 Annex A 8.29 FAQ
- ISO 27002 Control 8.29
- Related ISO 27001 Controls
- Further Reading
- ISO 27001 Control and Attributes Table
- Stuart Barker
Key Takeaways
- ISO 27001 Annex A 8.29 requires that security is not just an afterthought but an integral part of the development lifecycle.
- It mandates that you define and implement security testing processes during development and before final acceptance, ensuring that no software or system goes live with known vulnerabilities.
Purpose & Definition
ISO 27001 Annex A 8.29 is a preventive control to validate if information security requirements are met when applications or code are deployed to the production environment.
The ISO 27001 standard defines ISO 27001 Annex A 8.29 as:
Security testing processes should be defined and implemented in the development life cycle.
ISO/IEC 27001:2022 Annex A 8.29 Security Testing in Development and Acceptance
White Label
ISO 27001 for Consultants
Custom-brandable ISO 27001 documentation for consultants. Easily rebrand, reduce project time, and deliver professional, high-value security systems. Focus on delivery, not drafting.
ISO 27001 Annex A 8.29 Requirements and Guidance
General Guidance
Testing is part of the software development lifecycle. There relevant clauses that you need include:
- ISO 27001 Annex A 5.8 Information Security In Project Management
- ISO 27001 Annex A 8.25 Secure Development Life Cycle
- ISO 27001 Annex A 8.26 Application Security Requirements
Secure Development Policy
The first step is to create, or download, your secure development policy. The ISO 27001 secure development policy set’s out what you do for information security in the context of software and systems development. It does not set out how you do it, as how you do it is covered in your processes.
Secure Development Policy Template
Secure Development Policy Example
An example of the ISO 27001 secure development policy.
Separate Environments
You are going to make sure that for the in-scope developments that you have separate development, test and live environments with the appropriate management and controls in place around this. This will include the process of promoting through those environments and the authorisations and approvals and acceptance.
Testing in a test environment should be conducted with the test environment matching as closely as possible to the production environment.
It is possible to have multiple test environments to facilitate different kinds of tests.
Further reading: ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments
Testing
All secure development will have testing. It is not our place, again, to tell you how to test as again, this is a profession in its own right but there must be a level of security testing in place that looks at the three parts of information security being confidentiality, integrity and availability.
Simple testing that can be considered here would be penetration testing, vulnerability testing, regression testing, code scanning and code testing.
We conduct testing for new information systems, upgrades, patches, new versions, changes.
When conducting security testing we are testing against a set of requirements that we have defined. This can be in the form of configurations in testing systems. Baseline configurations and using the features of testing tools to enhance our capability.
Testing should consider including:
- Access restrictions
- Global admin restrictions
- Cryptography and encryption
- User authentication
- Secure Configurations
Testing is always proportionate to the risk, importance and data being processed, stored or transmitted.
Test Plans
Testing is conducted against test plans. When creating test plans consideration is given to
- Schedules of Activity
- Schedules of Tests
- Inputs and Expected Outputs
- Evaluation Criteria
- Follow Up Actions
Knowledge and Experience
The standard touches on this in a number of areas, having people with the right knowledge and / or experience to perform the role. This is also true of testing. Having a competency matrix and being able to point to qualifications or certifications will help. Where there are gaps a plan, such as training, should be in place but these are basic HR and people functions that are common place in any role.
Who Tests
Who conducts the test should be considered and be proportionate to the test being performed. Consider testing by the actual developer, peer review testing and also independent testing. An independent test has to be completed before go live.
Types of Testing
There are many types of testing that can be undertaken. The following is not an exhaustive list but
- Code Review
- Vulnerability Scanning
- Penetration Testing
- Peer Review
- Automated Testing
- Manual Testing
Documentation
Be sure to have documented evidence of tests conducted as well as of the acceptance criteria, process and sign offs.
Outsourced Development
If you outsource your development then the third party supplier controls will apply. The main thing is to ensure they meet your requirements for secure development but all relevant controls will apply to them.
Further reading: ISO 27001 Annex A 8.30 Outsourced Development
Check Your Work?
You built it yourself. Maybe with AI. But will it pass the audit?
Don’t gamble – let an ISO 27001 Lead Auditor check your work.
How to implement ISO 27001 Annex A 8.29
Implementing security testing throughout the development lifecycle ensures that vulnerabilities are identified and remediated before code reaches production. Following these technical steps will help your organisation satisfy the rigorous requirements of ISO 27001 Annex A 8.29 while maintaining a robust security posture.
1. Formalise a Security Testing Framework
- Develop a comprehensive testing strategy that defines the scope, frequency, and types of security tests required for different risk levels of software.
- Establish a Requirements Traceability Matrix (RTM) to link security functional requirements directly to specific test cases.
- Result: A structured roadmap that ensures no critical security controls are overlooked during the development phase.
2. Integrate SAST and SCA into CI/CD Pipelines
- Provision Static Application Security Testing (SAST) tools to scan source code for common weaknesses like SQL injection or Cross-Site Scripting (XSS).
- Automate Software Composition Analysis (SCA) to identify known vulnerabilities in third-party libraries and open-source dependencies.
- Result: Immediate feedback for developers, allowing for the rapid remediation of flaws during the initial coding process.
3. Execute Dynamic Application Security Testing (DAST)
- Deploy DAST scanners against running staging environments to identify runtime vulnerabilities and configuration errors that static scans might miss.
- Configure authenticated scans to test the security of user sessions, privilege escalation paths, and API endpoints.
- Result: Verification of the application’s security state within a functional environment that mimics production.
4. Sanitise Test Data for Acceptance Environments
- Provision data masking or anonymisation tools to ensure that Personally Identifiable Information (PII) is never used in non-production environments.
- Establish strict IAM roles to restrict access to the tools used for generating or cloning test data sets.
- Result: Compliance with data protection regulations while providing developers with realistic data for effective testing.
5. Conduct Penetration Testing and Vulnerability Assessments
- Formalise a Rules of Engagement (ROE) document for independent penetration testers to simulate real-world attacks against the application.
- Utilise automated vulnerability assessment tools to perform periodic scans of the underlying infrastructure and container images.
- Result: Identification of complex security gaps that automated pipeline tools often fail to detect.
6. Enforce Formal Acceptance Sign-Off
- Require a technical sign-off from the security lead or Data Protection Officer (DPO) before any major release is promoted to production.
- Validate that all “High” and “Critical” vulnerabilities discovered during testing have been successfully remediated or formally risk-accepted.
- Result: A verifiable audit trail demonstrating that the application meets all defined security criteria prior to deployment.
ISO 27001 Annex A 8.29 Implementation Checklist
ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance Implementation Checklist:
- Develop a comprehensive security testing strategy that outlines the scope, objectives, and methodology for security testing throughout the development lifecycle.
- Perform regular code reviews to identify and address security vulnerabilities, such as buffer overflows, SQL injection, and cross-site scripting.
- Utilise automated vulnerability scanning tools to identify and assess security vulnerabilities in applications, systems, and networks.
- Perform penetration testing to simulate real-world attacks and identify exploitable vulnerabilities.
- Promote and enforce secure coding practices throughout the development process, including the use of secure coding standards and guidelines.
- Leverage secure development frameworks and libraries to minimise the risk of common vulnerabilities.
- Implement a secure configuration management process to ensure that systems and applications are configured securely.
- Include security testing as part of the acceptance testing process to ensure that the system meets security requirements before deployment.
- Continuously monitor security testing activities, analyse test results, and identify areas for improvement.
- Document all security testing activities, including test plans, results, and remediation actions. Communicate security testing results to relevant stakeholders.
ISO 27001 Toolkit
Everything a business needs to do ISO 27001 and get ISO 27001 certified in the ISO 27001 Toolkit: Business Edition
ISO 27001 Annex A 8.29 Audit Checklist
ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance Audit Checklist:
- 1. Review Security Testing Strategy
- 2. Assess Code Review Processes
- 3. Examine Vulnerability Scanning Activities
- 4. Evaluate Penetration Testing Procedures
- 5. Assess Secure Coding Practices
- 6. Review the Use of Secure Development Frameworks and Libraries
- 7. Examine Secure Configuration Management:
- 8. Assess Acceptance Testing for Security
- 9. Review Security Testing Documentation
- 10. Evaluate Continuous Improvement
ISO 27001 Annex A 8.29 FAQ
While the standard does not mandate specific tools, a compliant approach typically includes a mix of automated and manual testing methods. Auditors commonly look for evidence of:
SAST (Static Application Security Testing): Scanning source code for vulnerabilities while developers are writing it.
DAST (Dynamic Application Security Testing): Testing the running application from the “outside” to find runtime issues.
Acceptance Testing: Validating that specific security requirements (e.g., “passwords must be encrypted”) function correctly before sign-off.
Security testing must occur throughout the development process, not just at the end. A secure lifecycle follows these stages:
During Development: Peer code reviews and automated static analysis (SAST).
During Acceptance (UAT): Functional security tests (e.g., verifying role-based access controls works).
Pre-Production: A final vulnerability scan or penetration test for major releases.
No, a full external penetration test is not required for every minor update. Instead, you should adopt a risk-based approach:
Minor Changes: Automated scans and peer reviews are usually sufficient.
Major Releases: Significant architecture changes or new features should undergo more rigorous testing or a focused pen test.
Annual Requirement: Most organisations conduct a full 3rd-party penetration test annually to satisfy broader audit requirements.
Auditors will ask for evidence that security was a “gate” for deployment, meaning unsafe code was stopped. Be prepared to show:
“Show me the test report for your last major release.”
“Do you have acceptance criteria that define when a vulnerability is too severe to release?”
“Show me evidence that a recent security bug was fixed before the code went to production.”
Responsibility is shared between developers and the security team (or designated tester).
Developers: Responsible for writing secure code and running initial unit tests/scans.
Project Managers/Product Owners: Responsible for ensuring “Acceptance Criteria” includes security requirements.
Testers/QA: Responsible for verifying that the security features actually work as intended during the Acceptance phase.
ISO 27002 Control 8.29
ISO 27002 Control 8.29 provides implementation guidance for ISO 27001 Security Testing in Development and Acceptance.
Related ISO 27001 Controls
There are several related ISO 27001 controls that are required for full compliance:
- ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities
- ISO 27001 Annex A 8.9 Configuration Management
- ISO 27001 Annex A 8.28 Secure Coding
- ISO 27001 Annex A 8.30 Outsourced Development
- ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments
- ISO 27001 Protection of Information Systems During Audit Testing
Further Reading
To learn more about ISO 27001 Annex A 8.29 Security Testing in Development and Acceptance read my ISO 27001:2022 Annex A 8.29 | Security Testing in Development and Acceptance Beginner’s Guide
ISO 27001 Security Testing in Development and Acceptance Explained explores the basics of the ISO 27002 control.
ISO 27001 Control and Attributes Table
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Preventive | Confidentiality | Identify | Application Security | Protection |
| Integrity | System and Network Security | |||
| Availability |
Stuart Barker
I am the ISO 27001 Ninja.
I help tech companies, start-ups, and small businesses implement information security management systems without the corporate bloat or massive consultant fees.
If you want to pass your audit the first time, book a call.
