ISO 27002:2022
Technological controls – ISO 27002:2022

ISO 27002:2022 8.29: Security testing in development and acceptance

Requires security testing processes to be defined and implemented within the development life cycle.

What else in your programme already covers this

This control maps to 100 controls across 28 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 Penetration testing methodology defined
  • 11.4.2 Internal penetration testing annually
  • 11.4.3 External penetration testing annually
  • 11.6.1 Payment page change and tamper detection
  • 6.2.1 Bespoke and custom software are developed securely, as follows: • Based on industry standards and/or best practices for secure development. • In accordance with PCI DSS (for example, secure authentication and logging). • Incorporating
  • 6.2.3 Custom software reviewed prior to production
  • 6.2.4 Coding practices prevent common attacks
  • 6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: • Reviewing public-facing web applications via manual or automated application
  • 6.3.1 Security vulnerabilities are identified and managed as follows: • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). • Vulnerabilities
  • 6.4.3 All payment page scripts that are loaded and executed in the consumer's browser are managed as follows: • A method is implemented to confirm that each script is authorized. • A method is implemented
  • 6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls

FedRAMP High · 10 controls

  • CA-8 Penetration Testing
  • CA-8(1) Penetration Testing | Independent Penetration Testing Agent or Team. Employ an independent penetration testing agent or team to perform penetration testing on the system or system components
  • CA-8(2) Penetration Testing | Red Team Exercises. Employ the following red-team exercises to simulate attempts by adversaries to compromise organizational systems in accordance with applicable rules of engagement: [Assignment: organization-defined red team exercises]
  • 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. Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses. Require the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing
  • SA-15 Development Process, Standards, and Tools. a. Require the developer of the system, system component, or system service to follow a documented development process that: 1. Explicitly addresses security and privacy requirements; 2. Identifies the
  • SI-6 Security and Privacy Function Verification. a. Verify the correct operation of [Assignment: organization-defined security and privacy functions]; b. Perform the verification of the functions specified in SI-6a [Selection (one or more): [Assignment: organization-defined system
  • SI-7(1) Integrity Checks

FedRAMP Moderate · 10 controls

  • CA-8 Penetration Testing
  • CA-8(1) Penetration Testing | Independent Penetration Testing Agent or Team. Employ an independent penetration testing agent or team to perform penetration testing on the system or system components
  • CA-8(2) Penetration Testing | Red Team Exercises. Employ the following red-team exercises to simulate attempts by adversaries to compromise organizational systems in accordance with applicable rules of engagement: [Assignment: organization-defined red team exercises]
  • 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. Require the developer of the system, system component, or system service to employ static code analysis tools to identify common flaws and document the results of
  • SA-11(2) Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses. Require the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing
  • SA-15 Development Process, Standards, and Tools. a. Require the developer of the system, system component, or system service to follow a documented development process that: 1. Explicitly addresses security and privacy requirements; 2. Identifies the
  • SI-6 Security and Privacy Function Verification. a. Verify the correct operation of [Assignment: organization-defined security and privacy functions]; b. Perform the verification of the functions specified in SI-6a [Selection (one or more): [Assignment: organization-defined system
  • 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

  • NIST800-CA-8 Penetration testing
  • NIST800-PM-14 Testing, Training, and Monitoring. Implement a process for ensuring that organizational plans for conducting security and privacy testing, training, and monitoring activities associated with organizational systems: Are developed and maintained; and Continue to be
  • NIST800-SA-11 Developer testing and evaluation
  • NIST800-SA-15 Development process, standards, and tools
  • NIST800-SC-38 Operations Security. Employ the following operations security controls to protect key organizational information throughout the system development life cycle: [organization-defined]
  • NIST800-SI-6 Security and Privacy Function Verification. Verify the correct operation of [organization-defined]; Perform the verification of the functions specified in SI-6a [organization-defined]; Alert [organization-defined] to failed security and privacy verification tests; and [organization-defined] when anomalies
  • NIST800-SI-7 Software, firmware, and information integrity

NIST SP 800-218 · 5 controls

NIST SP 800-53 Revision 5.1 HIGH · 5 controls

  • CA-8 Penetration Testing
  • CM-3(2) Testing, Validation, and Documentation of Changes
  • SA-11 Developer Testing and Evaluation
  • SA-15 Development Process, Standards, and Tools. a. Require the developer of the system, system component, or system service to follow a documented development process that: 1. Explicitly addresses security and privacy requirements; 2. Identifies the
  • SI-6 Security and Privacy Function Verification. a. Verify the correct operation of [Assignment: organization-defined security and privacy functions]; b. Perform the verification of the functions specified in SI-6a [Selection (one or more): [Assignment: organization-defined system

Australian Information Security Manual · 4 controls

  • ISM-0402 Software is comprehensively tested for vulnerabilities, using SAST, DAST and SCA prior to
  • ISM-2028 All software artefacts are tested to detect known weaknesses using static application secu
  • ISM-2032 The build solution ensures that all automated testing is completed without warnings, alert
  • ISM-2062 Unit testing and integration testing, covering both positive and negative use cases, are u

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 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 systems

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

NIST SP 800-53 Rev 5 MODERATE · 3 controls

  • CM-3(2) Testing, Validation, and Documentation of Changes
  • SA-11 Developer Testing and Evaluation
  • SA-15 Development Process, Standards, and Tools. a. Require the developer of the system, system component, or system service to follow a documented development process that: 1. Explicitly addresses security and privacy requirements; 2. Identifies the

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 COSO principle 10: Selects and develops control activities to mitigate risks
  • SOC2-CC8.1 Change management processes are in place

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

NIST SP 800-161 Rev 1 · 1 control

NIST SP 800-171 Rev 3 · 1 control

PCI SSF · 1 control

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 100 it maps to, and the evidence behind each claim, over MCP and REST.

MCP endpointAll ISO 27002:2022 controls