PCI DSS 6.5.1 expects every change to production system components to carry a reason and description, a documented security impact, approval by authorized parties, testing that it does not weaken security, and procedures to return to a secure state if it fails. Code changes also need testing against 6.2.4. This is not legal advice.
The required elements
From the SAQ D text for 6.5.1, changes follow established procedures that include:
- Reason for, and description of, the change.
- Documentation of security impact.
- Documented approval by authorized parties.
- Testing to verify the change does not adversely impact system security.
- For bespoke and custom software, testing for compliance with 6.2.4 before deployment.
- Procedures to address failures and return to a secure state.
The expected testing is to examine change control procedures and trace recent changes to change control documentation.
Mapping each element to a pull request
| Element | Where it can live |
|---|---|
| Reason and description | Pull request description linked to a ticket |
| Security impact | A short checklist field: touches auth, payment data, logging, crypto? |
| Approval | Required reviewer or release approver |
| Testing | CI results attached to the merge |
| 6.2.4 testing | Tests or scans for injection, XSS, access control and similar attacks |
| Rollback | Revert plan or deployment rollback note |
This is one way to meet the intent. Any system that makes the evidence traceable works.
Significant change adds more
6.5.2 says that after a significant change all applicable PCI DSS requirements are confirmed in place on new or changed systems, with documentation updated. Those changes also feed the annual scope confirmation in 12.5.2. See our post on scope after code changes.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a pull request fails a check.
Quick check
Does a hotfix skip change control?
The text has no emergency exemption. Keep a fast path that still records the elements, even if the paperwork is completed right after.
Do configuration changes count?
6.5.1 covers changes to all system components in the production environment, not just code.
On Safeguard: policies, gates and guardrails can require checks to pass before a merge, and compliance and evidence automation can keep the resulting records. Try the free scan at gold.safeguard.sh/scan.
Sources
Wording is from v4.0. Confirm in the current version.
Last reviewed: 19 October 2026.
