ISO 27002:2022
Technological controls – ISO 27002:2022

ISO 27002:2022 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.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

This control maps to 99 controls across 30 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

PCI DSS 4.0 · 11 controls

  • 11.4.1 11.4.1 Penetration testing methodology defined and implemented
  • 11.4.2 11.4.2 Internal penetration testing annually and after change
  • 11.4.3 11.4.3 External penetration testing annually and after change
  • 11.6.1 11.6.1 Payment page tamper detection
  • 6.2.1 6.2.1 Secure development of bespoke and custom software
  • 6.2.3 6.2.3 Code review before release
  • 6.2.4 6.2.4 Engineering techniques against common software attacks
  • 6.4.1 6.4.1 Public web application review or automated protection
  • 6.3.1 6.3.1 Vulnerability identification and risk ranking
  • 6.4.3 6.4.3 Payment page script management
  • 6.5.3 6.5.3 Separate pre-production from production

FedRAMP High · 10 controls

  • CA-8 Penetration Testing
  • CA-8(1) Penetration Testing | Independent Penetration Testing Agent or Team (CA-8(1))
  • CA-8(2) Penetration Testing | Red Team Exercises (CA-8(2))
  • CM-3(2) Testing, Validation, and Documentation of Changes
  • SA-11 Developer Testing and Evaluation
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses (SA-11(2))
  • SA-15 Development Process, Standards, and Tools (SA-15)
  • SI-6 Security and Privacy Function Verification (SI-6)
  • SI-7(1) Integrity Checks

FedRAMP Moderate · 10 controls

  • CA-8 Penetration Testing
  • CA-8(1) Penetration Testing | Independent Penetration Testing Agent or Team (CA-8(1))
  • CA-8(2) Penetration Testing | Red Team Exercises (CA-8(2))
  • CM-3(2) Testing, Validation, and Documentation of Changes
  • SA-11 Developer Testing and Evaluation
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses (SA-11(2))
  • SA-15 Development Process, Standards, and Tools (SA-15)
  • SI-6 Security and Privacy Function Verification (SI-6)
  • SI-7(1) Integrity Checks

CIS Controls v8 · 7 controls

  • CIS-16.1 Establish and Maintain a Secure Application Development Process
  • CIS-16.12 Implement Code-Level Security Checks
  • CIS-16.13 Conduct Application Penetration Testing
  • CIS-16.14 Conduct Threat Modeling
  • CIS-18.1 Establish and Maintain a Penetration Testing Program
  • CIS-18.2 Perform Periodic External Penetration Tests
  • CIS-18.5 Perform Periodic Internal Penetration Tests

NIST SP 800-53 Rev 5 · 7 controls

NIST SP 800-218 · 5 controls

Australian Information Security Manual · 4 controls

  • ISM-0402 SAST, DAST and SCA testing
  • ISM-2028 Testing software artefacts for known weaknesses
  • ISM-2032 Completing automated testing before builds
  • ISM-2062 Positive and negative unit and integration testing

ISO 27001:2022 · 4 controls

  • 8.25 Secure development life cycle
  • 8.26 Application security requirements
  • 8.28 Secure coding
  • 8.29 Security testing in development and acceptance

ISO/IEC 27041:2015 · 4 controls

  • 5.8.1 5.8.1 General principles of verification
  • 5.8.2 5.8.2 Verification of processes
  • 5.9.5 5.9.5 Failed validation
  • 7.2 7.2 Pre-validation preparation

ISO/IEC 42001:2023 · 4 controls

  • A.5 Assessing impacts of AI systems
  • A.6 AI system life cycle
  • A.6.2.4 AI system verification and validation
  • A.7.2 Data for development and enhancement of AI system

Azure Security Benchmark · 3 controls

  • ASBv3-DS-4 Integrate static application security testing into DevOps pipeline
  • ASBv3-DS-5 Integrate dynamic application security testing into DevOps pipeline
  • ASBv3-PV-7 Conduct regular red team operations

C5 (Germany) · 3 controls

  • C5-DEV-06 Testing changes
  • C5-OPS-19 Managing Vulnerabilities, Malfunctions and Errors - Penetration Tests
  • C5-PSS-02 Identification of Vulnerabilities of the Cloud Service

AWS Well-Architected Security Pillar · 2 controls

  • SEC11-BP02 Automate testing throughout the development and release lifecycle
  • SEC11-BP03 Perform regular penetration testing

CMMC 2.0 · 2 controls

Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 · 2 controls

DORA · 2 controls

  • DORA-Art.24 General requirements for the performance of digital operational resilience testing
  • DORA-Art.25 Testing of ICT tools and systems

ISO 27701:2019 · 2 controls

  • 6.11.1 Security requirements of information systems
  • 6.11.2 Security in development and support processes

NIS2 Directive · 2 controls

  • Art.21.2.e Security in acquisition, development and maintenance, including vulnerability handling and disclosure
  • Art.21.2.f Policies and procedures to assess the effectiveness of the cybersecurity risk-management measures

NIST Cybersecurity Framework 2.0 · 2 controls

  • NIST-CSF-ID.IM-01 Improvements are identified from evaluations
  • NIST-CSF-PR.PS-06 Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle

NIST SP 800-172 · 2 controls

  • 3.12.1e Penetration Testing by Independent Agents
  • 3.14.7e Verify Correctness of Security Functions

SOC 2 · 2 controls

  • SOC2-CC5.1 CC5.1 Selecting control activities that mitigate risk (COSO principle 10)
  • SOC2-CC8.1 CC8.1 Managing changes to procedures, software, data and infrastructure

ANSI/ASIS PAP.1-2012 Physical Asset Protection · 1 control

  • B.6.14 B.6.14 Testing: acceptance and periodic checks

Australia Consumer Data Right - Banking (CDR) · 1 control

  • AUCDR-IS-STEP4 Step 4 - Implement a formal controls assessment program

CFTC System Safeguards (17 CFR 37, 38, 39, 49) · 1 control

  • CFTC-SS-5 Systems Development and Quality Assurance Category

CNCF Security Technical Advisory Group (TAG) · 1 control

EU Cyber Resilience Act · 1 control

MTCS (Singapore) · 1 control

NIST SP 800-161 Rev 1 · 1 control

NIST SP 800-171 Rev 3 · 1 control

PCI SSF · 1 control

  • SSLC-7.1 Security Testing

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in Technological controls – ISO 27002:2022

You are reading one control. How much of ISO 27002:2022 have you already done?

ISO 27002:2022 8.29 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.

If you hold NIST SP 800-53 Rev 584.9% covered · 14 gapsIf you hold FedRAMP Moderate80.6% covered · 18 gapsIf you hold Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.174.2% covered · 24 gapsIf you hold C5 (Germany)69.9% covered · 28 gapsIf you hold NIST Cybersecurity Framework 2.063.4% covered · 34 gapsIf you hold NIST SP 800-171 Rev 357% covered · 40 gaps

Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.

See the released pairs, $299 eachBrowse the graph free

Query this from an agent

The graph holds this control, the 99 it maps to, and the evidence behind each claim, over MCP and REST.

MCP endpointAll ISO 27002:2022 controls