#iso27002/2022/EN

## 8.29 Security testing in development and acceptance

| Control type | Information security properties           | Cybersecurity concepts | Operational capabilities                                                           | Security domains |
| ------------ | ----------------------------------------- | ---------------------- | ---------------------------------------------------------------------------------- | ---------------- |
| #Preventive  | #Confidentiality #Integrity #Availability | #Identify              | #Application_security #Information_security_assurance #System_and_network_security | #Protection      |

**Control**
Security testing processes should be defined and implemented in the development life cycle.

**Purpose**
To validate if information security requirements are met when applications or code are deployed to the production environment.

**Guidance**
New information systems, upgrades and new versions should be thoroughly tested and verified during the development processes. Security testing should be an integral part of the testing for systems or components.

Security testing should be conducted against a set of requirements, which can be expressed as functional or non-functional. Security testing should include testing of:

a\) security functions \[e.g. user authentication (see [8.5](a-8.5-Secure-authentication.md)), access restriction (see [8.3](a-8.3-Information-access-restriction.md)) and use of cryptography (see [8.24](a-8.24-Use-of-cryptography.md))\];

b\) secure coding (see [8.28](a-8.28-Secure-coding.md));

c\) secure configurations (see >8.9>, >8.20and >8.22>) including that of operating systems, firewalls and other security components.

Test plans should be determined using a set of criteria. The extent of testing should be in proportion to the importance, nature of the system and the potential impact of the change being introduced. The test plan should include:

a\) detailed schedule of activities and tests;

b\) inputs and expected outputs under a range of conditions;

c\) criteria to evaluate the results;

d\) decision for further actions as necessary.

The organization can leverage automated tools, such as code analysis tools or vulnerability scanners, and should verify the remediation of security related defects.

For in-house developments, such tests should initially be performed by the development team. Independent acceptance testing should then be undertaken to ensure that the system works as expected and only as expected (see [5.8](a-5.8-Information-security-in-project-management.md)). The following should be considered:

a\) performing code review activities as a relevant element for testing for security flaws, including unanticipated inputs and conditions;

b\) performing vulnerability scanning to identify insecure configurations and system vulnerabilities;

c\) performing penetration testing to identify insecure code and design.

For outsourced development and purchasing components, an acquisition process should be followed. Contracts with the supplier should address the identified security requirements (see [5.20](a-5.20-Addressing-information-security-within-supplier-agreements.md)). Products and services should be evaluated against these criteria before acquisition.

Testing should be performed in a test environment that matches the target production environment as closely as possible to ensure that the system does not introduce vulnerabilities to the organization’s environment and that the tests are reliable (see [8.31](a-8.31-Separation-of-development-test-and-production-environments.md)).

**Other information**
Multiple test environments can be established, which can be used for different kinds of testing (e.g. functional and performance testing). These different environments can be virtual, with individual configurations to simulate a variety of operating environments.

Testing and monitoring of test environments, tools and technologies also needs to be considered to ensure effective testing. The same considerations apply to monitoring of the monitoring systems deployed in development, test and production settings. Judgeme nt is needed, guided by the sensitivity of the systems and data, to determine how many layers of meta-testing are useful.