Security testing in development and acceptance
Purpose
Define and run security testing throughout development and acceptance before code reaches production.
How to meet this control
In short: Define and implement security testing in the development lifecycle.
- Step 01Make security testing an integral, scheduled part of testing for every new system and significant change
- Step 02Run automated SAST, DAST and dependency scanning in the pipeline and verify fixes before release
- Step 03Build test plans with inputs, expected outputs, pass criteria and decision points, scaled to system importance
- Step 04Have the development team test first, then run independent acceptance testing separate from the builders
- Step 05Commission penetration testing for high-value or internet-facing systems and track findings to closure
- Step 06Gate releases so code does not reach production until security tests pass
Tip: Gate releases on security tests (SAST/DAST/dependency scans).
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Make security testing an integral part of testing for all new systems and versions
- ›Test against functional and non-functional requirements covering security functions and config
- ›Build test plans with schedules, inputs, expected outputs, criteria and decision points
- ›Scale the extent of testing to the system importance and impact of the change
- ›Use automated tools such as code analysers and vulnerability scanners and verify fixes
- ›For in-house work, have the development team test first, then independent acceptance testing
- ›Include code reviews, vulnerability scanning and penetration testing
- ›For purchased components, follow an acquisition process with contractual security requirements
Audit evidence to keep
- - Security testing plan with criteria and decision points
- - Pipeline configuration running SAST, DAST and dependency scans
- - Release gate evidence requiring security tests to pass
- - Independent acceptance testing record separate from developers
- - Penetration test report with findings tracked to closure
Common mistakes
- - Treating security review as optional when release pressure rises
- - Testing only happy paths and missing abuse cases
- - Not linking production changes to approvals and rollback plans
Owner, cadence, and proof
Assign one accountable owner for A.8.29. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.