PCI DSS 4.0
Req 6: Secure Systems and Software

PCI DSS 4.0 6.5.1: 6.5.1 Change control procedure for production

Every change to a system component in production must follow established procedures that include: the reason for the change and a description of it; documented security impact; documented approval from authorised parties; tests showing the change leaves system security intact; for changes to custom and bespoke software, tests of every update against Requirement 6.2.4 ahead of release to production; and procedures for handling failures and returning to a secure state. It applies to all entities. Objective under the customized approach: every change is tracked, authorised and assessed for its impact and security effects, and changes are handled so they do not unintentionally affect the security of system components.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

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

NIST SP 800-53 Rev 5 · 17 controls

FedRAMP High · 15 controls

  • CM-2(2) Automation Support for Accuracy and Currency
  • CM-2(3) Retention of Previous Configurations
  • CM-3 Configuration Change Control
  • CM-3(2) Testing, Validation, and Documentation of Changes
  • CM-3(4) Security and Privacy Representatives
  • CM-4 Impact Analyses
  • CM-5 Access Restrictions for Change
  • CM-5(5) Access Restrictions for Change | Privilege Limitation for Production and Operation (CM-5(5))
  • CM-8(1) Updates During Installation and Removal
  • MA-3 Maintenance Tools (MA-3)
  • SA-10 Developer Configuration Management
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SA-3 System Development Life Cycle
  • SA-8 Security and Privacy Engineering Principles
  • SR-11(2) Component Authenticity | Configuration Control for Component Service and Repair (SR-11(2))

FedRAMP Moderate · 15 controls

  • CM-2(2) Automation Support for Accuracy and Currency
  • CM-2(3) Retention of Previous Configurations
  • CM-3 Configuration Change Control
  • CM-3(2) Testing, Validation, and Documentation of Changes
  • CM-3(4) Security and Privacy Representatives
  • CM-4 Impact Analyses
  • CM-5 Access Restrictions for Change
  • CM-5(5) Access Restrictions for Change | Privilege Limitation for Production and Operation (CM-5(5))
  • CM-8(1) Updates During Installation and Removal
  • MA-3 Maintenance Tools (MA-3)
  • SA-10 Developer Configuration Management
  • SA-11(1) Developer Testing and Evaluation | Static Code Analysis (SA-11(1))
  • SA-3 System Development Life Cycle
  • SA-8 Security and Privacy Engineering Principles
  • SR-11(2) Component Authenticity | Configuration Control for Component Service and Repair (SR-11(2))

CMMC 2.0 · 8 controls

ISO 27001:2022 · 7 controls

  • 5.37 Documented operating procedures
  • 8.19 Installation of software on operational systems
  • 8.25 Secure development life cycle
  • 8.26 Application security requirements
  • 8.27 Secure system architecture and engineering principles
  • 8.32 Change management
  • 8.4 Access to source code

ISO 27701:2019 · 7 controls

  • 5.5.5 Documented information
  • 5.6.1 Operational planning and control
  • 6.11 Systems acquisition, development and maintenance
  • 6.11.2 Security in development and support processes
  • 6.9 Operations security
  • 6.9.1 Operational procedures and responsibilities
  • 6.9.5 Control of operational software

ISO 27002:2022 · 5 controls

  • 8.19 Installation of software on operational systems
  • 8.25 Secure development life cycle
  • 8.32 Change management
  • 8.4 Access to source code
  • 8.9 Configuration management
  • NIST-CSF-ID.AM-08 Systems, hardware, software, services, and data are managed throughout their life cycles
  • NIST-CSF-ID.RA-07 Changes and exceptions are managed, assessed for risk impact, recorded, and tracked
  • NIST-CSF-PR.PS-01 Configuration management practices are established and applied
  • NIST-CSF-PR.PS-05 Installation and execution of unauthorized software are prevented
  • NIST-CSF-PR.PS-06 Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle
  • CFTC-SS-32 Timely Advance Notice of Material Planned Changes
  • CFTC-SS-4 Systems Operations Category
  • CFTC-SS-5 Systems Development and Quality Assurance Category

ISO/IEC 42001:2023 · 3 controls

  • 7.5.2 Creating and updating documented information
  • 8.3 AI risk treatment
  • A.6.2.2 AI system requirements and specification

NIST SP 800-161 Rev 1 · 3 controls

  • P1-3.3.1 P1-3.3.1 Change-control procedures for all changes, including emergencies
  • P1-3.3.2 P1-3.3.2 Changes authorised with security impact understood first
  • P1-3.3.4 P1-3.3.4 Rollback prepared for every change

SOC 2 · 3 controls

  • SOC2-CC3.4 CC3.4 Identifying and assessing significant changes (COSO principle 9)
  • SOC2-CC5.2 CC5.2 General controls over technology (COSO principle 11)
  • SOC2-CC8.1 CC8.1 Managing changes to procedures, software, data and infrastructure
  • ASBv3-PV-4 Audit and enforce secure configurations for compute resources
  • DS-6 Enforce security of workload throughout DevOps lifecycle

C5 (Germany) · 2 controls

  • C5-DEV-03 Policies for changes to information systems
  • C5-DEV-09 Approvals for provision in the production environment

ISO 22301:2019 · 2 controls

  • 6.3 Planning changes to the business continuity management system
  • 8.3.5 Implementation of solutions

NIST SP 800-171 Rev 3 · 2 controls

NIST SP 800-218 · 2 controls

CIS Controls v8 · 1 control

  • CIS-16.1 Establish and Maintain a Secure Application Development Process

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 Req 6: Secure Systems and Software

You are reading one control. How much of PCI DSS 4.0 have you already done?

PCI DSS 4.0 6.5.1 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of PCI DSS 4.0 your existing evidence covers. Hold ISO 27001:2022 and 139 of 280 PCI DSS 4.0 controls already carry evidence.

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. 415 were rejected on the ISO 27001:2022 pair alone.

Query this from an agent

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