Back

Separate the production environment from development environment or test environment for the change control process.


CONTROL ID
11864
CONTROL TYPE
Maintenance
CLASSIFICATION
Preventive

SUPPORTING AND SUPPORTED CONTROLS




This Control directly supports the implied Control(s):
  • Establish, implement, and maintain a change control program., CC ID: 00886

There are no implementation support Controls.


SELECTED AUTHORITY DOCUMENTS COMPLIED WITH




  • The FI should ensure all changes are adequately tested in the test environment. Test plans for changes should be developed and approved by the relevant business and IT management. Test results should be accepted and signed off before the changes are deployed to the production environment. (§ 7.5.3, Technology Risk Management Guidelines, January 2021)
  • changes are developed and verified in another environment, sufficiently segregated from production so as to avoid any compromise of information security; (47(d)., APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
  • changes to the production environment (including planned and emergency changes to software, hardware and data) developed and verified in another environment, sufficiently segregated from production so as to avoid any compromise of IT security; (Attachment A ¶ 2(a), The AD_offical_Name should be: APRA Prudential Practice Guide 234: Management of security risk in information and information technology, May 2013)
  • A financial institution should ensure that measures are in place to mitigate the risk of unintentional alteration or intentional manipulation of the ICT systems during development and implementation in the production environment. (3.6.2 69, Final Report EBA Guidelines on ICT and security risk management)
  • A financial institution should implement separate ICT environments to ensure adequate segregation of duties and to mitigate the impact of unverified changes to production systems. Specifically, a financial institution should ensure the segregation of production environments from development, testing… (3.6.2 72, Final Report EBA Guidelines on ICT and security risk management)
  • Production environments are separated physically or logically by non-production environments in order to avoid unauthorised access or changes to the production data. Production data is not replicated in test or development environments in order to maintain their confidentiality. (Section 5.11 BEI-11 Basic requirement ¶ 1, Cloud Computing Compliance Controls Catalogue (C5))
  • Separate development/test environments from production environments, and enforce the separation with access controls. (6.4.1, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.1 April 2015)
  • Separate development/test environments from production environments, and enforce the separation with access controls. (6.4.1, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, v3.2.1)
  • Separate development/test environments from production environments, and enforce the separation with access controls. (6.4.1, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.2)
  • Are development/test environments separate from the production environment? (6.4.1 (a), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.1)
  • Are development/test environments separate from the production environment? (6.4.1(a), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.2)
  • Are development/test environments separate from the production environment? (6.4.1 (a), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.1)
  • Are development/test environments separate from the production environment? (6.4.1(a), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.2)
  • Examine network documentation and network device configurations to verify that the development/test environments are separate from the production environment(s). (6.4.1.a, Payment Card Industry (PCI) Data Security Standard, Testing Procedures, Version 3.2)
  • 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) ¶ 1, StateRAMP Security Controls Baseline Summary High Sensitivity Level, Version 1.1)
  • Prior to implementing any change in the production environment, test the changes in a test environment or test the changes in a production environment where the test is performed in a manner that minimizes adverse effects, that models the baseline configuration to ensure that required cyber security… (CIP-010-2 Table R1 Part 1.5 Requirements 1.5.1., North American Electric Reliability Corporation Critical Infrastructure Protection Standards Cyber Security - Configuration Change Management and Vulnerability CIP-010-2, Version 2)
  • Prior to implementing any change in the production environment, test the changes in a test environment or test the changes in a production environment where the test is performed in a manner that minimizes adverse effects, that models the baseline configuration to ensure that required cyber security… (CIP-010-3 Table R1 Part 1.5 Requirements 1.5.1., North American Electric Reliability Corporation Critical Infrastructure Protection Standards Cyber Security - Configuration Change Management and Vulnerability CIP-010-3, Version 3)
  • Independence of non-production environments from production environments to maintain data integrity and resilience. (App A Objective 3:8a, FFIEC Information Technology Examination Handbook - Architecture, Infrastructure, and Operations, June 2021)
  • 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) High Baseline Controls, FedRAMP Baseline Security Controls, 8/28/2018)
  • Analyze changes to the system in a separate test environment before implementation in an operational environment, looking for security and privacy impacts due to flaws, weaknesses, incompatibility, or intentional malice. (CM-4(1) ¶ 1, Control Baselines for Information Systems and Organizations, NIST SP 800-53B, High Impact Baseline, October 2020)
  • Analyze changes to the system in a separate test environment before implementation in an operational environment, looking for security and privacy impacts due to flaws, weaknesses, incompatibility, or intentional malice. (CM-4(1) ¶ 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST Special Publication 800-161, Revision 1, Appendix A, C-SCRM Level 3 Controls)
  • 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) ¶ 1 High Baseline Controls, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • 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) ¶ 1, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, High Impact Baseline, Revision 4)
  • 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) ¶ 1, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • Analyze changes to the system in a separate test environment before implementation in an operational environment, looking for security and privacy impacts due to flaws, weaknesses, incompatibility, or intentional malice. (CM-4(1) ¶ 1, Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)