Security testing in development and acceptance

What the requirement 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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Security testing needs a scope and a response. The guidance asks for the plan, the test, the finding and the retest.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep security test plans with schedules, inputs, expected outputs, evaluation criteria and decisions, scaled to the system's importance and change impact and one live sample together.

Evidence an assessor asks for

• Security test planningSecurity test plans with schedules, inputs, expected outputs, evaluation criteria and decisions, scaled to the system's importance and change impact
• Security test planningSecurity test results covering authentication, access restriction, cryptography, secure coding and configuration
• Security test planningIndependent acceptance test records including code review, vulnerability scanning and penetration test findings
• Security test planningRecords verifying that security defects were remediated before go-live
• Security test planningSupplier contracts and pre-acquisition evaluations against security requirements for purchased or outsourced components
• Security test planningEvidence the test environment closely matches production

The question an assessor will ask

An assessor will ask for security test plans with schedules, inputs, expected outputs, evaluation criteria and decisions, scaled to the system's importance and change impact, then trace it to the system it protects. For A.8.29 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common 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

Before the next audit

Before the next audit, check one live sample for this gap: security testing is skipped for minor releases that still change security functions.