All 93 controls · Technological controls
Control 8.29
Security testing in development and acceptance
What ISO/IEC 27002:2022 control 8.29 asks for, in our own words, with the five published attribute values, the evidence an auditor asks for and the gaps commonly found. ISO/IEC 27028 is the guidance that explains how to use these values.
What the control asks
Security testing processes are to be defined and carried out within the development life cycle. Purpose: check that code and applications satisfy their security requirements by the time they reach production. Guidance: test and verify new systems, upgrades and new versions thoroughly during development, with security testing an integral part of testing systems and components. Test against a set of functional or non-functional requirements, covering security functions such as user authentication (8.5), access restriction (8.3) and cryptography (8.24); secure coding (8.28); and secure configuration of operating systems, firewalls and further security components (8.9, 8.20, 8.22). Base test plans on defined criteria and scale the testing to the system's importance and nature and to how much the change could affect; plans should include a detailed schedule, inputs and expected outputs under various conditions, criteria for judging results, and decisions on further action. Automated tools such as code analysers and vulnerability scanners can be used, and remediation of security defects must be verified. For in-house development the development team tests first, followed by independent acceptance testing to confirm the system behaves as expected and only as expected (5.8), considering code review for security flaws including unexpected inputs and conditions, vulnerability scanning for insecure configuration and system weaknesses, and penetration testing to expose weak code and design. For externally developed software and purchased components, follow an acquisition process in which supplier contracts address the identified requirements (5.20) and products and services are evaluated against them before purchase. Test in an environment as close as possible to production so tests are reliable and the system does not introduce vulnerabilities (8.31). Other information: several test environments, possibly virtual, can serve different kinds of testing; the test environments, tools and even the monitoring systems themselves need testing and monitoring, with judgement on how much of this is worthwhile depending on how sensitive the systems and data are.
Purpose in the standard’s terms, in our words: Checks that code and applications satisfy security requirements before they reach production.
Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Identify; Application security, Information security assurance, System and network security; Protection.
The five attribute values
These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.
| Control type | Preventive |
|---|---|
| Information security properties | ConfidentialityIntegrityAvailability |
| Cybersecurity concepts | Identify |
| Operational capabilities | Application securityInformation security assuranceSystem and network security |
| Security domains | Protection |
Evidence an auditor asks for
The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.
- Security test plans with schedules, inputs, expected outputs, evaluation criteria and decisions, scaled to the system's importance and change impact
- Security test results covering authentication, access restriction, cryptography, secure coding and configuration
- Independent acceptance test records including code review, vulnerability scanning and penetration test findings
- Records verifying that security defects were remediated before go-live
- Supplier contracts and pre-acquisition evaluations against security requirements for purchased or outsourced components
- Evidence the test environment closely matches production
Where audits commonly find gaps
- Security testing is skipped for minor releases that still change security functions
- Developers test their own code with no independent acceptance testing
- Penetration test findings are released into production unresolved
- Test environments differ significantly from production, so results are unreliable
What ISO/IEC 27028 changes for this control
It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. It crosses 3 operational capabilities, so two teams share the work and the owner column matters. Its earlier numbering (14.2.8, 14.2.9) is kept in the register so an older audit file can still be traced.
The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.
Controls that share its values
Source for this page
- ISO/IEC 27002:2022, the control catalogue and Table A.1. The reference record of the 93 controls, their five attribute values, purpose, evidence and gaps. The published standard is at https://www.iso.org/standard/75652.html.
- ISO/IEC 27028, official record. Stage 60.00 under publication, edition 1, committee, abstract and the dated lifecycle. Retrieved 20 October 2026.
Retrieved 2026-10-20. The requirement above is our statement of the clause in our own words; the official text is linked so you can check it.
The attribute kit, USD 799 one off. The 109-row register with all five values, the evidence list, a dated plan and the extension worksheet, as PDF, CSV and XLSX.