8.29 Security testing in development and acceptance
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.
Source: ISO/IEC 27002:2022, 8.29. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.
ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
none for this control
periodic reviewEvidence produced at each review
- Security test results covering authentication, access restriction, cryptography, secure coding and configuration · Identity provider / directory
- Independent acceptance test records including code review, vulnerability scanning and penetration test findings · Vulnerability scanner / patch tooling
- Records verifying that security defects were remediated before go-live · Document repository
- Supplier contracts and pre-acquisition evaluations against security requirements for purchased or outsourced components · Vendor register / contract repository
- Evidence the test environment closely matches production · Cloud console / configuration management
governing documentDocuments that govern the control
- Security test plans with schedules, inputs, expected outputs, evaluation criteria and decisions, scaled to the system's importance and change impact · Policy repository / GRC workspace
First move
Common gaps auditors find
- 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
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet