6.5 Change management: PCI DSS requirements and evidence

What PCI DSS 6.5 change management requires in practice

When an assessor or payment partner asks for proof that changes to the cardholder data environment are controlled, they want to see that every change is documented, approved, tested and reversible, and that the environment is still protected once the change lands. Requirement 6.5 is the PCI DSS requirement that sets those expectations for all system components in scope. It has six sub-requirements: documented change procedures (6.5.1), confirmation of PCI DSS controls after significant change (6.5.2), separation of pre-production from production (6.5.3), role separation between those two environments (6.5.4), no live PANs in pre-production (6.5.5), and removal of test data and accounts before a system goes live (6.5.6). Together they address a simple risk: an unreviewed change can quietly open a path to card data, switch off a control, or put production data into a test environment where fewer protections apply.

In practice the hard part is not writing a change procedure. It is making every change follow it. Emergency fixes made directly on a production server, shared administrator accounts that hide who made a change, and developers who hold production access for convenience are the usual reasons assessors find gaps. Each one leaves no approval record, no test evidence and no clear owner. Start by listing where changes can enter the CDE, including hotfixes, configuration edits, infrastructure code and vendor-managed components, and then decide which of them count as significant under the standard's examples of significant change (confirm the current list with your assessor). Changes to directory services, time servers or logging often surprise teams because they sit outside the application stack.

A workable starting point is a single change record per production change that holds the security impact, the approver, the test results and the rollback steps, with emergency changes raised and approved after the fact within a defined window. Ticketing tools such as the open-source GLPI Assistance module can hold that record, and protected branches in GitLab Community Edition can stop direct pushes to the branches that feed production. Ask your QSA how they expect the emergency path and the post-change confirmation to be evidenced before you design the workflow, because the sampling they perform will decide whether your records are enough.

Which changes and systems fall under PCI DSS 6.5 change management

Requirement 6.5 applies to changes across every system component in or connected to the cardholder data environment, not only application code. The cards below cover the scoping decisions that determine how much change work your team must document, test and confirm.

All components in or connected to the CDE

Change procedures under 6.5 reach every system component that stores, processes or transmits account data, plus systems that could affect its security. That includes servers, network devices, databases, endpoints and virtual machines. Start by checking your current system inventory against the CDE boundary, because a component missing from the inventory is usually a component whose changes go unrecorded. Confirm with your assessor how connected systems are treated in your scope.

Custom and off-the-shelf software

Bespoke applications and vendor products both fall under change control, but the work differs. Changes to custom code need testing against the secure coding checks in 6.2.4, while vendor product updates need documented security impact and testing before production. Check whether your team applies the same approval record to a vendor patch as to an internal release, since assessors look for one consistent process.

Significant change triggers

PCI SSC FAQ 1317 lists activities that count as significant change, including new CDE hardware or software and changes to data flows or storage. A change to the CDE boundary also triggers the confirmation of PCI DSS controls. Build a short trigger list into your change form so that the team classifies each request before work begins, not after deployment.

Supporting infrastructure changes

Directory services, time servers and logging platforms are often overlooked in change records, yet FAQ 1317 treats changes to this supporting infrastructure as significant. A change to time synchronization or log forwarding can break audit evidence for other requirements. Include these services in your change inventory and name an owner for each, so that their changes receive the same approval and testing as the payment systems they support.

Third-party and managed service changes

Vendors that maintain your payment platform, hosting provider updates and SaaS releases can change systems you do not directly administer. Ask each third party how it notifies customers of changes, whether it records security impact, and how you receive evidence of its testing. Contract terms should state these duties, because your 6.5 record must still show who approved and tested a change that reached your CDE.

Emergency and out-of-cycle changes

Urgent fixes still require documented security impact, approval and a return-to-secure-state procedure if the change fails. Emergency changes are a common gap because teams bypass the ticket queue under pressure. Define in advance who can approve an urgent change, how it is recorded within the same workflow, and when it must be reviewed after deployment. Confirm these steps with your assessor before an incident forces the question.

How an assessor tests PCI DSS 6.5 change management

This table compares each sub-requirement of Requirement 6.5 by how an assessor tests it, the evidence usually requested and the findings that appear most often. Read each row as a checklist of what to have ready before the assessor samples recent production changes and follows each one from request to closure.

Sub-requirement	How the assessor tests it	Evidence requested	Common findings
6.5.1 Change procedures	Selects recent production changes and checks each against the documented change process end to end	Change tickets with security impact notes, approvals, test results and documented rollback steps	Changes made without tickets, approvals recorded after deployment, or no rollback procedure
6.5.2 Confirming controls after significant change	Identifies significant changes in the sample period and verifies that PCI DSS requirements were re-checked afterward	Post-change validation records covering affected requirements, and the significant change classification for each change	Significant changes such as new CDE components or data flow changes not classified as significant
6.5.3 Pre-production separated from production	Confirms environments are distinct in network, access and data, and that changes pass through pre-production	Environment inventory, network diagrams, access lists and deployment logs showing promotion path	Shared credentials or networks between test and live, or production hosts used for development
6.5.4 Role separation	Reviews who can request, approve and deploy changes and checks that no one approves their own change	Role matrix, approval workflow settings, and account lists for change and production access	Same person requesting, approving and deploying, or no procedural control where team is small
6.5.5 No live PANs in pre-production	Inspects test datasets and sample data for live card numbers and checks how test data is created	Data sourcing procedure, test data samples, masking or generation method and scan results	Production database copies loaded into test without masking or removal
6.5.6 Test data and accounts removed before go-live	Checks production systems and recent releases for leftover test data, test accounts and debug settings	Pre-release checklist, account audit output and configuration review records	Default or test accounts left enabled, or test records found in production after release

Implementing PCI DSS 6.5 change management in order

This sequence turns Requirement 6.5 from a policy statement into a working change process, with each step leaving an artifact an assessor can sample. Work through it in order, because later steps depend on the change record and environment separation built earlier.

Define the change procedure and roles
Write the change management procedure that covers every system component in scope, and name who raises, reviews, approves, tests and deploys changes. Document the security impact assessment that must accompany each production change, and confirm that the same people are not able to both develop and deploy without a documented control. The output is an approved procedure with a role matrix, signed off by the owner of the cardholder data environment. Ask your QSA or internal assessor to confirm the roles match what your tools actually allow.
Set up the change record and approval gate
Configure a ticketing system so every production change has a single record holding the description, security impact, test evidence, approver and implementation window. GLPI's Assistance module supports tickets, problems and changes following ITIL practices, and Zammad provides a ticket system if you need lighter request handling. The approval gate is complete when no change can move to implementation without a recorded approval from an authorized party. Sample a handful of closed changes to confirm each one carries all required fields.
Separate pre-production from production
Build pre-production environments that are logically separated from the production cardholder data environment, with separate credentials, network paths and access lists. Document the separation in your network diagram and confirm that changes are tested in pre-production before they reach production. The output is an environment inventory and a reviewed diagram showing the boundary. Note that any system that could affect the security of the cardholder data environment, such as directory services or logging, is also a candidate for change control.
Lock down deployment rights
Restrict who can push or merge code and deploy to production. In GitLab Community Edition, protected branches let you limit push and merge rights to specific roles, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Where your team is small, the SAQ D note to Requirement 6.5.4 permits procedural controls, such as developers using separate user-level accounts in production. The output is an exported permissions list and branch protection settings captured as evidence.
Establish the test data rule
Write and enforce a rule that live primary account numbers never appear in pre-production or test systems, and that test data and accounts are removed before a system goes live. Use synthetic or masked data for testing, and scan pre-production stores for card number patterns before each release. The output is a test data standard, a record of the scans and a sign-off that test accounts were removed before go-live. Confirm with your assessor how they expect you to evidence the absence of live data.
Write rollback and failure procedures
Document the steps that return a changed system to a secure state if an implementation fails, including backup restoration, configuration reversion and the criteria for triggering rollback. Test these steps in pre-production before relying on them, and record the test. The output is a rollback runbook linked to each change record, plus evidence from at least one rehearsal. Make sure the runbook covers custom software as well as vendor components.
Confirm PCI DSS controls after significant change
After any change that counts as significant, confirm that the relevant PCI DSS requirements still operate as intended. PCI SSC FAQ 1317 lists examples, including new cardholder data environment hardware or software, changes to data flows or storage, changes to the CDE boundary, and changes to supporting infrastructure such as directory services, time servers and logging. Record the confirmation in the change record, with the requirements checked and the person who verified them. The step is complete when every significant change in the period has a matching confirmation.

Evidence that passes PCI DSS 6.5 change management

An assessor testing Requirement 6.5 samples real changes and asks for the paperwork behind each one, so the evidence has to exist as a running habit rather than a file assembled in the weeks before a review. The six cards below cover the documents and records that connect a change from request through testing, separation and post-change confirmation. Keep each one current between assessments and make sure any item can be retrieved for a sampled change within a short time.

Change procedure document

This is the written procedure that defines how every change to a system component is requested, documented, approved, tested and closed. For 6.5, it must describe the security impact review, the approval step, the rollback path for a failed change and the roles involved. Review it at least annually and whenever the toolchain or ownership changes, and confirm that the version in force is the one staff actually follow.

Change records with security impact

Each production change needs a ticket that records the documented security impact, the named approver and the approval date, linked to the work performed. Ticketing tools such as GLPI's Assistance module can track changes following ITIL practices, which helps keep these fields mandatory. Sample a few records yourself before an assessment and check that none were approved after deployment.

Test results and custom software checks

Keep test evidence for each change, including confirmation that security controls still work as intended. For custom software, store the results of code checks that address the practices in 6.2.4, such as static analysis output from a pipeline scan. A tool such as Semgrep Community Edition can run in CI/CD and produce retained reports, but confirm which rules and languages your codebase actually covers.

Environment separation records

Assessors look for proof that pre-production and production are separated, through network controls, distinct accounts and access records. Protected branches in GitLab Community Edition can block direct pushes and restrict who can merge, and exported settings give a dated record of that configuration. Also document the role separation approach, including any procedural controls a small team uses in place of separate people.

Test data sanitization records

Records should show that live PANs were not copied into testing environments and that test data and accounts were removed before go-live. Keep the data refresh procedure, the masking or generation method used, and a log of each refresh or cleanup with its date and owner. Ask your team to confirm what sanitization actually runs, because a documented method that nobody executes will not pass sampling.

Post-change control confirmations

After a significant change, such as new CDE hardware or software, a data flow change or a change to supporting services like logging or time servers, you need a dated confirmation that the PCI DSS requirements still hold. Attach the scope review, the check results and the sign-off to the change ticket. Use the significant change criteria in PCI SSC FAQ 1317 to decide which changes trigger this step.

What PCI DSS 6.5 change management costs to meet

This table compares the main cost components of meeting Requirement 6.5, who is paid for each, whether the cost is one-time or recurring, and what moves it up or down. No price list is published for these items, so use it to structure a quote request and to decide which parts to build in-house and which to buy.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Tooling or licenses for change tickets and approvals	Software vendor or internal platform team	Recurring (subscription) or one-time (self-hosted setup)	Number of users and approvers. Self-hosted open source such as GLPI can remove license fees, but hosting and upkeep remain. Confirm feature fit and support terms before choosing.
Engineering time to build the pipeline and gates	Internal engineers or an implementation partner under a fixed-scope agreement	One-time, with ongoing adjustments	Number of repositories, deployment targets and how many approval steps the gates must enforce. Reusing protected-branch and CI templates shortens the build.
Change process upkeep	Change manager, security reviewers and service owners	Recurring	Frequency of production changes and the number of significant changes that need impact review. Clear templates for security impact notes reduce review time.
Pre-production environment upkeep	Platform or infrastructure team	Recurring, with a one-time build	Size of the environment, how closely it mirrors production and how often it is refreshed. Keeping test data synthetic avoids extra controls on live data.
External testing or review	Independent testers or reviewers, paid per scope	Recurring at each release cycle or change cycle	Application size, code churn and whether custom software changes need review against Requirement 6.2.4. Agree the scope in writing before work starts.
Assessor sampling effort	Internal staff preparing evidence, and the QSA or internal assessor who samples it	Recurring at each assessment	Number of changes sampled, quality of evidence and how well change records link to tests and approvals. Ask the assessor how they sample before the assessment begins.

Open-source tools that support PCI DSS 6.5 evidence

Requirement 6.5 is judged on records: who approved each change, what its security impact was, and whether it was tested before it reached production. The four tools below can hold part of that record, but none of them decides whether a change is compliant. Your change process defines what the tools must capture, and your assessor decides whether the evidence is sufficient.

Change records in GLPI

The Assistance module of GLPI follows ITIL practices and lets teams raise, track and process change records alongside tickets and problems. For 6.5.1, a change record can hold the documented security impact, the approver and the test result, and its statistics help show how many changes went through the process. Confirm that your approval workflow forces these fields to be completed before a change can close. GLPI is licensed under GPL-3.0-or-later, so review the terms with your legal team if you plan to modify it.

Ticket handling in Zammad

Zammad is a web-based helpdesk that gathers requests from email, chat, telephone and social media into one ticket system. It is useful where change requests arrive from business users and need a documented trail from request to closure. Confirm that tickets can be linked to the production change that resulted from them, and that closed tickets remain retrievable for your assessor. Zammad is licensed under AGPL-3.0-only, which carries network-use obligations if you modify and host it for others, so check the terms before customizing it.

Approval gates in GitLab

GitLab Community Edition uses protected branches to restrict which roles can push or merge to a branch. Setting push access to no one blocks direct pushes to production branches, and keeping force pushes disabled preserves the commit history an assessor may sample. Together these settings produce evidence that code reached production through an approved merge rather than a direct edit. Confirm that your approvers are separate from the developers who wrote the change, since role separation under 6.5.4 is tested alongside this control. GitLab Community Edition is licensed under MIT.

Security scanning with Semgrep

Semgrep Community Edition scans code in languages including Java, JavaScript, TypeScript, Python, Go and Terraform, using community or custom rules. Running it in CI/CD produces a scan result attached to each pipeline run, which can serve as testing evidence that security was not adversely affected by a custom software change. Confirm that your languages are covered, that scan results block merges on findings you have agreed to treat as blocking, and that you can explain any exceptions. Semgrep Community Edition is licensed under LGPL-2.1-only, so confirm how its terms apply to your build and distribution.

Who owns PCI DSS 6.5 change management and what to outsource

Your organization owns Requirement 6.5 in full. Change management is an operating process, so the people who approve, deploy and record changes must be your staff, and no outside party can accept the accountability for them. Your team decides what counts as a change, who authorizes it, how security impact is assessed and what happens when a deployment fails.

Change policy and procedure: write and maintain the documented procedure that covers every system component in scope, including who may raise, approve and close a change.
Security impact assessment: decide how each production change is checked for security impact before approval, and keep the record.
Significant change decisions: classify which changes trigger confirmation of PCI DSS requirements, using the activities listed in FAQ 1317 as a starting point.
Role separation: assign developers, reviewers and approvers so that no one person can change production without oversight, or document the procedural controls that serve a small team.
Evidence ownership: review tickets, approvals and test results on a regular basis so the records assessors sample are complete.

Before engaging anyone else, confirm that a named owner can explain every step of a change from request to rollback.

Where organizations fall short on 6.5 and how to close each gap

Assessors find the same weaknesses in change control again and again: changes that bypass the record, shared access in production, and real card data drifting into places it does not belong. Each card below names one gap, explains why it matters for Requirement 6.5, and gives the closing action to take before the next assessment.

Emergency changes made without records

Teams fix a production outage directly, then intend to document it later, and often never do. Requirement 6.5.1 expects every production change, including urgent ones, to carry a documented security impact, an approval and a test result. Close the gap by routing emergency work through a fast-track ticket type in your change system, with a required approval field and a post-change review within a defined window your policy sets.

Shared or developer production accounts

When developers log in to production with a shared administrative account, no one can tell who made a change, and role separation under Requirement 6.5.4 fails. The SAQ D note allows small teams to use procedural controls, such as a developer working in production through a separate user-level account. Close the gap by issuing named accounts, removing shared credentials, and checking the production access list against the team roster each review cycle.

Live PANs copied into test databases

Teams often refresh a test database from a production backup to get realistic data, which places live primary account numbers in a pre-production environment. Requirement 6.5.5 prohibits live PANs in pre-production systems, so this copy can pull test systems into scope. Close the gap by generating synthetic or masked datasets, blocking direct restores from production backups, and scanning pre-production stores for PAN patterns.

Missing security impact notes

Change tickets that describe what will be deployed but not how it could affect security leave assessors with no evidence of review. Requirement 6.5.1 expects each production change to record its security impact, so the approver can judge whether controls such as logging, access or encryption are affected. Close the gap by adding a mandatory security impact field to the change template and requiring the security approver to sign off on it before deployment.

No PCI DSS check after significant change

A new payment service, a data flow change or a firewall rule update can alter the cardholder data environment without anyone confirming that controls still work. Requirement 6.5.2 expects PCI DSS requirements to be confirmed after a significant change, and PCI SSC FAQ 1317 lists examples such as changes to the CDE boundary and supporting services like logging and time servers. Close the gap by defining which change types count as significant, then attaching a short control verification step to each one.

Test data and accounts left at go-live

Demo accounts, sample card numbers and debug endpoints often survive a release because no one owns their removal. Requirement 6.5.6 expects test data and test accounts to be removed from production systems before they go live. Close the gap by adding a pre-release checklist item that lists known test artifacts, and by having a second person verify the production account and database inventory before sign-off.

How much effort PCI DSS 6.5 change management takes

How much effort does PCI DSS 6.5 change management take?

The effort depends mostly on how many systems are in the cardholder data environment, how often they change, and how much of the change process already runs through tickets and approvals. A team with a single payment application that deploys monthly has a much smaller job than one with many services, shared infrastructure and frequent releases. Most of the one-time work is writing the change procedure, mapping existing changes to it, and collecting evidence from the last several cycles. The recurring work is running each change through the procedure and keeping the records complete. Ask any provider for a written estimate that lists the systems in scope, the number of change types and the evidence to be produced.

Can an in-house team do PCI DSS 6.5 change management without a partner?

Yes, in most organizations the in-house team owns this work, because the controls govern how the organization itself makes changes. Teams usually struggle in three places: defining what counts as a significant change, keeping pre-production free of live card data, and producing consistent evidence across many small changes. An outside partner can help build the procedure and tooling, but the organization must still approve changes and operate the controls. A partner does not issue the assessment result, so the internal team should be ready to explain every decision to the assessor.

What do PCI DSS 6.5 controls need from engineers and change managers?

Engineers need to record the security impact of each production change, use separate environments, and avoid copying live card numbers into test data. Change managers need to define approval rules, confirm that approvers are authorized, and check that testing and rollback steps are documented before a change is released. Both groups must agree on what triggers a review after a significant change, such as new hardware, altered data flows or changes to logging and time services. Clear roles reduce disputes during assessment. The SAQ D note for this requirement allows small teams to separate duties through procedural controls, so a developer may use a separate user-level account in production rather than a shared admin login.

Which tools help engineers produce change records and code scan evidence?

A ticketing system is the usual backbone for change records. GLPI's Assistance module follows ITIL practices and supports tickets, problems and changes with plannings and a Kanban view, and Zammad is a web-based helpdesk that centralizes requests in one ticket system. For code changes, GitLab Community Edition supports protected branches that restrict who can push or merge, block direct pushes and keep force pushes disabled unless allowed. Semgrep Community Edition can run in CI/CD pipelines to scan repositories. Confirm that each tool meets your evidence needs and your own licensing review before adopting it.

How long does it take to get ready for a PCI DSS 6.5 assessment?

No general duration is published here, so treat any single number with caution. Readiness depends on whether a documented change procedure already exists, how many changes the team has recorded in the past year, and whether pre-production data has ever been checked for live card numbers. Organizations with mature change tickets and approval records often need less preparation than those that must reconstruct evidence from chat logs and emails. Ask your assessor which evidence samples they will request, then work backward from that list to a schedule. A partner can propose a timeline in a written scope before work starts.

Can a partner run the PCI DSS assessment for us?

A partner can prepare your systems, procedures and evidence, but it cannot perform the assessment or issue the result. Validation is carried out by a Qualified Security Assessor who completes a Report on Compliance, or by the organization itself through a Self-Assessment Questionnaire with an Attestation of Compliance, depending on the entity's eligibility. DeployOpen prepares systems and evidence for assessments and does not issue audit reports, attestations or certifications. Keep the implementation partner and the assessor independent, and confirm the assessor's role in writing before the engagement begins.

What is the difference between a significant change and a routine change under 6.5?

A significant change is one that can affect the security of the cardholder data environment, and PCI SSC FAQ 1317 lists examples such as new CDE hardware or software, changes to data flows or storage, changes to the CDE boundary, and changes to supporting infrastructure like directory services, time servers and logging. These changes require confirmation that PCI DSS controls still work after the change. Routine changes, such as minor content edits that do not touch security-relevant components, still need documentation and approval under the change procedure but do not trigger the same post-change confirmation. Define the difference in your procedure so engineers can classify changes consistently.

How DeployOpen prepares PCI DSS 6.5 change management evidence

DeployOpen plans and implements the change management tooling and procedures behind Requirement 6.5 inside your own infrastructure, then documents the evidence an assessor will sample. Your organization owns its change approvals and PCI DSS decisions, and only an independent QSA issues the assessment report.

How we scope

Written scope lists which systems, pipelines and change channels fall under 6.5 for your cardholder data environment.
Scope identifies which changes count as significant, such as new CDE hardware, data flow changes or boundary changes.
Scope names the pre-production environments, roles and approvers that the written agreement covers before work starts.

How we build

We configure change request workflows in self-hosted ITSM tooling so each production change records security impact and approval.
We set protected branches and push restrictions in your source control so unreviewed code cannot reach production.
We separate pre-production from production and document controls that keep live PANs out of test data and test accounts.

How we hand over

Handover includes configuration records, procedure documents and sample change tickets showing the approval and rollback steps.
Deliverables map each sub-requirement of 6.5 to the system, configuration and record that shows it operating.
Your team receives runbooks for confirming PCI DSS requirements after significant changes, so the evidence is repeatable.

How we support

Ongoing support and upgrades of the change tooling are available as a retainer, agreed in writing.
Retainers can cover periodic review of change records ahead of your assessor's sampling, scoped in advance.
Ask any provider to confirm in writing which parts of 6.5 remain your team's responsibility after handover.