Back

Test all software changes before promoting the system to a production environment.


CONTROL ID
01106
CONTROL TYPE
Testing
CLASSIFICATION
Detective

SUPPORTING AND SUPPORTED CONTROLS



This Control directly supports the implied Control(s):
  • Establish, implement, and maintain system testing procedures., CC ID: 11744

There are no implementation support Controls.


SELECTED AUTHORITY DOCUMENTS COMPLIED WITH



  • A formal acceptance process should be established to ensure that only properly tested and approved systems are promoted to the production environment. System and user acceptance testing should be carried out in an environment separated from the production environment. Production data should not be u… (4.2.4, Hong Kong Monetary Authority: TM-G-1: General Principles for Technology Risk Management, V.1 – 24.06.03)
  • The organization must confirm that the quality of the software was tested by the software package developer before the software is implemented. This is a control item that constitutes a greater risk to financial information. This is an IT general control. (App 2-1 Item Number III.5(13), Appendix 1 Correspondence of the System Management Standards - Supplementary Edition to other standards)
  • The FI should ensure that full regression testing is performed before system rectification or enhancement is implemented. Users whose systems and operations are affected by the system changes should review and sign off on the outcome of the tests (Refer to Appendix A for details on Systems Security … (§ 6.2.3, Monetary Authority of Singapore: Technology Risk Management Guidelines)
  • All issues and software defects discovered from the source code review and application security testing should be tracked. Major issues and software defects should be remediated before production deployment. (§ 6.1.7, Technology Risk Management Guidelines, January 2021)
  • The FI should perform regression testing for changes (e.g. enhancement, rectification, etc.) to an existing IT system to validate that it continues to function properly after the changes have been implemented. (§ 5.7.4, Technology Risk Management Guidelines, January 2021)
  • The organization should validate the interaction between the software and the Operating System and the network in a test environment before implementing on an operational system. (Control: 0284 Bullet 2, Australian Government Information Security Manual: Controls)
  • Software should be tested or reviewed for vulnerabilities before placing it in the production environment. (Control: 0402, Australian Government Information Security Manual: Controls)
  • The organization should test the Intrusion Detection System and Intrusion Prevention System rule sets before implementing them. (Control: 1031, Australian Government Information Security Manual: Controls)
  • All software should be reviewed and tested for security vulnerabilities before being used in the production environment. The testing should be conducted by an independent tester, not the developer. (§ 3.5.28, § 3.7.31, Australian Government ICT Security Manual (ACSI 33))
  • A methodology for testing applications prior to their first use and after material modifications shall be defined and introduced. The scope of the tests shall include the functionality of the application, the security controls and system performance under various stress scenarios. The organisational… (II.6.41, Circular 10/2017 (BA): Supervisory Requirements for IT in Financial Institutions, 14.09.2018)
  • Ensure that business process owners and IT stakeholders evaluate the outcome of the testing process as determined by the test plan. Remediate significant errors identified in the testing process, having completed the suite of tests identified in the test plan and any necessary regression tests. Foll… (AI7.7 Final Acceptance Test, CobiT, Version 4.1)
  • Test changes independently in accordance with the defined test plan prior to migration to the operational environment. Ensure that the plan considers security and performance. (AI7.6 Testing of Changes, CobiT, Version 4.1)
  • Host devices shall validate the authenticity and integrity of any software update or upgrade prior to installation. (14.5.3 (1) ¶ 1, IEC 62443-4-2: Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components, Edition 1.0)
  • For custom code changes, testing of updates for compliance with PCI DSS Requirement 6.5 before being deployed into production? (6.4.5.3 (b), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.1)
  • For custom code changes, testing of updates for compliance with PCI DSS Requirement 6.5 before being deployed into production? (6.4.5.3(b), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.2)
  • For custom code changes, testing of updates for compliance with PCI DSS Requirement 6.5 before being deployed into production? (6.4.5.3 (b), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.1)
  • For custom code changes, testing of updates for compliance with PCI DSS Requirement 6.5 before being deployed into production? (6.4.5.3(b), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.2)
  • All software changes should be tested prior to being implemented into the live environment. (§ 5.1.1 thru § 5.1.1.5, Payment Card Industry (PCI) Payment Application Data Security Standard, Version 1.1)
  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. (6.5.1 Bullet 5, Payment Card Industry Data Security Standard Requirements and Testing Procedures, Defined Approach Requirements, Version 4.0)
  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. (6.5.1 Bullet 5, Self-Assessment Questionnaire A-EP and Attestation of Compliance for use with PCI DSS Version 4.0)
  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. (6.5.1 Bullet 5, Self-Assessment Questionnaire C and Attestation of Compliance for use with PCI DSS Version 4.0)
  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. (6.5.1 Bullet 5, Self-Assessment Questionnaire D for Merchants and Attestation of Compliance for use with PCI DSS Version 4.0)
  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. (6.5.1 Bullet 5, Self-Assessment Questionnaire D for Service Providers and Attestation of Compliance for use with PCI DSS Version 4.0)
  • The Change Management process should include testing changes to ensure that they are made correctly and securely. (CF.07.06.02a-2, The Standard of Good Practice for Information Security)
  • Prior to changes being applied to the live environment, changes should be tested to help determine the expected results (e.g., the results of deploying a patch into the live environment). (CF.07.06.03d, The Standard of Good Practice for Information Security)
  • The Change Management process should include testing changes to ensure that they are made correctly and securely. (CF.07.06.02a-2, The Standard of Good Practice for Information Security, 2013)
  • Prior to changes being applied to the live environment, changes should be tested to help determine the expected results (e.g., the results of deploying a patch into the live environment). (CF.07.06.03d, The Standard of Good Practice for Information Security, 2013)
  • Changes to the production environment shall be documented, tested and approved prior to implementation. (RM-02, The Cloud Security Alliance Controls Matrix, Version 1.3)
  • Changes to the production environment shall be documented, tested and approved prior to implementation. Production software and hardware changes may include applications, systems, databases and network devices requiring patches, Service Packs, and other updates and modifications. (RM-02, The Cloud Security Alliance Controls Matrix, Version 1.3)
  • Modified or new configuration items should be accepted after following the procedures established in the acceptance plan. The configuration management documentation should ensure that a review of all changes to configuration items are adequate and appropriate. (§ 13.2, ISO 15408-3 Common Criteria for Information Technology Security Evaluation Part 3, 2008)
  • For software systems assigned to Class B and Class C software safety classes, the medical device manufacturer shall perform regression testing to verify that defects have not been introduced into software integrated previously. (§ 5.6.6, ISO 62304 - 2006 Medical device software - Software life cycle processes, 2006)
  • The entity's security policies include testing, evaluating, and authorizing system components before implementation. (Security Prin. and Criteria Table § 1.2 h, Appendix B: Trust Services Principles and Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, TSP Section 100 Principles and Criteria)
  • The entity's system availability and related security policies include testing, evaluating, and authorizing system components before implementation. (Availability Prin. and Criteria Table § 1.2 h, Appendix B: Trust Services Principles and Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, TSP Section 100 Principles and Criteria)
  • The entity's system processing integrity and related security policies include testing, evaluating, and authorizing system components before implementation. (Processing Integrity Prin. and Criteria Table § 1.2 h, Appendix B: Trust Services Principles and Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, TSP Section 100 Principles and Criteria)
  • The entity's policies related to the system's protection of confidential information and security include testing, evaluating, and authorizing system components before implementation. (Confidentiality Prin. and Criteria Table § 1.2 h, Appendix B: Trust Services Principles and Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, TSP Section 100 Principles and Criteria)
  • The security program, in relation to protecting personal information, should include procedures to test and evaluate system components before they are implemented. (Table Ref 8.2.1, Generally Accepted Privacy Principles (GAPP), CPA and CA Practitioner Version, August 2009)
  • Prior to adding a new applicable Cyber Asset to a production environment, perform an active vulnerability assessment of the new Cyber Asset, except for CIP Exceptional Circumstances and like replacements of the same type of Cyber Asset with a baseline configuration that models an existing baseline c… (CIP-010-2 Table R3 Part 3.3 Requirements ¶ 1., North American Electric Reliability Corporation Critical Infrastructure Protection Standards Cyber Security - Configuration Change Management and Vulnerability CIP-010-2, Version 2)
  • Does the documented Change Management/Change Control Process include testing prior to deployment? (§ I.2.22.1, Shared Assessments Standardized Information Gathering Questionnaire - I. Information Systems Acquisition Development & Maintenance, 7.0)
  • CMS business partners are required to use a CMS-contracted third party to conduct a security test and evaluation (ST&E) of new functionality before releasing the system into production and the ST&E must include penetration testing. (§ 5 ¶ 1, CMS Business Partners Systems Security Manual, Rev. 10)
  • The organization must control program changes through the testing process. The updated programs are only moved to production after documented approval from system development management and users. (CSR 6.3.12, Pub 100-17 Medicare Business Partners Systems Security, Transmittal 7, Appendix A: CMS Core Security Requirements CSR, March 17, 2006)
  • Changes to software shall be validated before approved and issued. The validation process and results shall be documented. (§ 820.70(i), 21 CFR Part 820, Subchapter H - Medical Devices, Part 820 Quality System Regulation)
  • (CC-2.1, Federal Information System Controls Audit Manual (FISCAM), February 2009)
  • Are the custom signature changes verified by an independent party? (IT - IDS IPS Q 31, Automated Integrated Regulatory Examination System (AIRES) IT Exam Questionnaires, version 073106A)
  • Are there implemented design controls to test software changes in a test setting? (IT - Member Online Services Q 7, Automated Integrated Regulatory Examination System (AIRES) IT Exam Questionnaires, version 073106A)
  • The organization should test, validate, and document changes prior to implementing them on the operational system. (App F § CM-3(2), Recommended Security Controls for Federal Information Systems, NIST SP 800-53)
  • The organization should analyze new software in a separate test environment before it is installed in an operational environment and should look for security impacts due to weaknesses, flaws, intentional malice, and incompatibility. (App F § CM-4(1), Recommended Security Controls for Federal Information Systems, NIST SP 800-53)
  • The organization analyzes changes to the information system in a separate test environment before implementation in an operational environment, looking for security impacts due to flaws, weaknesses, incompatibility, or intentional malice. (CM-4(1), Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Deprecated, Revision 4, Deprecated)
  • The organization analyzes changes to the information system in a separate test environment before implementation in an operational environment, looking for security impacts due to flaws, weaknesses, incompatibility, or intentional malice. (CM-4(1), Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, High Impact Baseline, Deprecated, Revision 4, Deprecated)