Open source ITSM for PCI DSS change management: what Requirement 6.5 asks for
A payments team has to show that every change to a system in the cardholder data environment (CDE) was approved, tested and reversible if it failed. An ITSM change record is the natural place to hold that evidence, because it already carries the request, the approver, the test result and the rollback plan in one timestamped trail. PCI DSS Requirement 6.5 has six sub-requirements (6.5.1 to 6.5.6), and sub-requirement 6.5.1 asks for documented security impact, approval by authorized parties, testing that security is not adversely affected, testing of custom software changes against 6.2.4, and procedures to return to a secure state on failure. A GLPI or iTop change template can be configured so that none of these fields can be skipped before a change moves to implementation. Confirm with your assessor which fields they will sample before you design the template.
Only PCI DSS v4.0.1 is active. Version 4.0 was retired on 31 December 2024, and v3.2.1 was retired on 31 March 2024. The PCI Security Standards Council owns and maintains the standard, but it does not enforce compliance or impose penalties. The individual payment brands decide which entities must validate and run any enforcement programs, so confirm your validation obligations with your acquirer or the relevant brand. The standard applies to merchants, processors, acquirers, issuers and service providers, and to any entity whose systems could affect the security of the CDE. Validation is documented on official templates: a Report on Compliance (ROC) completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire (SAQ), each with an Attestation of Compliance (AOC). Certificates are not accepted as validation.
DeployOpen plans, configures and documents the ITSM platform and the change evidence it produces, and prepares the systems and records for your assessor. DeployOpen does not issue ROCs, SAQs, AOCs or any other attestation, and the assessment itself remains with your independent assessor. Before scoping, ask your QSA whether a significant change under PCI SSC FAQ 1317 (new CDE hardware or software, changes to data flows, CDE boundary or supporting services such as directory services and logging) will be routed through the same change template, and whether the customized approach is under consideration for any requirement. That decision changes how much of the evidence must be structured in the tool.
How each Requirement 6.5 sub-requirement maps to ITSM configuration
This table maps each sub-requirement of PCI DSS Requirement 6.5 to the function it asks for and to a GLPI or iTop configuration that produces the evidence. Read each row as a design target for your change template, then confirm the exact wording of each sub-requirement with your assessor and the current SAQ or ROC template. The main takeaway is that most of the 6.5 evidence comes from a small set of mandatory fields, approval steps and linked CMDB items, so configure them once and enforce them for every production change.
| Sub-requirement | What the function must do | How to configure GLPI or iTop |
|---|---|---|
| 6.5.1 Change procedure and security impact | Document the security impact, obtain approval from authorized parties, test that security is not adversely affected, test custom code changes, and define how to return to a secure state on failure | Create a change template with mandatory security impact and test evidence fields, an approval step tied to authorized approver groups, and a back-out task that must be completed before closure |
| 6.5.2 Confirmation after significant change | Confirm that applicable PCI DSS requirements are still met after a significant change to the CDE | Add a yes/no significant change field and a required post-change checklist task that lists affected requirements, linked to the CDE asset group and its CIs |
| 6.5.3 Pre-production and production separation | Keep pre-production environments separate from production | Set an environment field on each configuration item (for example, production, staging, test) and block production change approval when a linked CI is not tagged production |
| 6.5.4 Separation of roles | Separate duties between people who develop or test changes and people who deploy them to production, with the SAQ D note allowing procedural controls for small teams | Use distinct requester, approver and implementer roles in the workflow, and record who executed the change. For small teams, document the procedural control and the separate user-level accounts used for production work |
| 6.5.5 No live PANs in pre-production | Do not use live primary account numbers in pre-production or test environments | Add a mandatory test data field on change records that confirms no live PANs were used, and link the test environment CIs so the attestation is traceable to each change |
| 6.5.6 Test data and accounts removed before go-live | Remove test data and test accounts from system components before they go live | Include a pre-go-live task on the change that records removal of test data and accounts, with an assigned owner and a completion timestamp before the change can move to closed |
How standard, normal and emergency changes differ under 6.5.1
A standard change is a low-risk, repeatable change with a pre-approved procedure, such as a routine certificate renewal or a patch applied through an established pipeline. Because the approval happens once when the template is defined, each individual change record carries a reference to that approved template rather than a fresh approval. The record still has to show that the change matches the approved pattern and that its security impact was considered. Illustrative example: a GLPI change linked to a patch template that was approved in advance, with the target asset list and the test result attached to the ticket.
- Template reference: Link each change to the approved standard change definition, including its version and approval date.
- Security impact statement: Record why the template still applies to this CDE component, including any change to data flows or the CDE boundary that would make it a significant change.
- Test evidence: Attach the result of the pre-production test run, or the pipeline output that shows the change was tested before deployment.
- Back-out procedure: Reference the rollback steps in the template and record the outcome if the back-out was used.
- Implementer and time: Record who made the change, when it was made, and that the production account used was the implementer's own user-level account.
Confirm with your assessor which change types you intend to treat as standard, and whether the template approval itself is recorded in the ITSM tool or in a separate controlled document that the ticket references.
A normal change is one that is assessed and approved for each occurrence, usually by a change advisory board (CAB) or an equivalent authorized group. For cardholder data environment components, the normal change record is where the documented security impact, approval and testing evidence for Requirement 6.5.1 are most visible. The record should show that the change was approved before it was made, by someone with authority over the system, and that the approval was based on the security analysis rather than only on schedule or business need.
- Security impact field: Describe the effect on the CDE, including whether the change falls under the significant change activities in PCI SSC FAQ 1317 and therefore triggers confirmation of PCI DSS requirements.
- CAB approval: Record the approvers, their roles, the decision and the date, with the approval captured before the implementation task starts.
- Testing record: Link the test plan and results, including confirmation that security controls still work and, for custom software, testing against Requirement 6.2.4.
- Separation evidence: Show that testing took place in pre-production, that the change was deployed by someone with the right role, and that no live PANs were used in test data.
- Return-to-secure-state plan: Record the failure criteria and the steps to restore a secure state, plus the result of any rollback.
Check that your ITSM workflow prevents a change from moving to implementation without the approval step being complete, and confirm with your QSA how they want the test evidence grouped.
An emergency change restores service or closes an active security risk faster than the normal CAB cycle allows. Requirement 6.5.1 still applies, so the record must show what was changed, why it could not wait, who authorized it, and what testing or review happened, either before or immediately after the change. The key difference is that approval and some testing may be documented after implementation. Assessors will expect that gap to be explained and closed quickly, not left open.
- Emergency justification: Record the incident or vulnerability reference, the reason normal change could not be used, and the time the change was started.
- Retrospective approval: Capture the authorizing manager or CAB delegate and the time approval was given, with a follow-up review at the next CAB.
- Compressed testing: Document what was tested before deployment and what was verified afterward, such as a targeted security check on the affected function.
- Linked records: Connect the emergency change to the incident ticket and any related problem record, so the trail from cause to fix is visible.
- Return-to-secure-state: Record the rollback plan agreed at the time, and whether it was executed.
Agree with your assessor in advance how emergency changes are defined and reviewed, and confirm whether your organization's policy allows emergency changes to bypass pre-production testing at all.
Requirement 6.5.1 expects documented procedures to return the system to a secure state if a change fails. The ITSM record is the place to show that these procedures exist, were attached to the change, and were used or confirmed unnecessary. This applies to every change type. The ITSM tool holds the record of the plan and outcome; it does not verify that the rollback worked on the system itself, so the technical evidence must come from the platform, configuration management or monitoring tools and be linked to the ticket.
- Rollback plan field: Make the back-out steps a required field for CDE changes, not an optional description.
- Failure criteria: Define the conditions that trigger a rollback, such as failed security checks or service health thresholds.
- Outcome entry: Record whether the change succeeded, failed and was rolled back, or failed and was fixed forward, with the time and person responsible.
- Post-change verification: Link the scan, configuration snapshot or log extract that shows the system returned to its approved baseline.
- Lessons and follow-up: Record any corrective action in a linked problem or task so repeated failures are tracked.
Confirm with your QSA which artifacts they expect to see for rollback, and whether a sample of failed changes must be shown in addition to successful ones.
Which open-source ITSM platforms fit PCI DSS change control
Two open-source ITSM platforms cover the change control needs described here, but they differ in how they model the CMDB and how much configuration they need. Each card below covers one decision or check that connects the platform choice to the approval, testing and back-out evidence a Requirement 6.5 assessment will ask for.
GLPI as the change and CMDB core
GLPI is distributed under GPL-3.0 and its 12.0.0 release came out on October 7, 2026. It combines tickets, assets, CMDB, contracts and data center infrastructure in one application, so change records can link directly to the components they touch. Confirm that its change workflow, approval steps and CMDB relationships meet your 6.5.1 evidence needs in the current release, since workflow features change between versions.
iTop and a customizable CMDB model
iTop is licensed under AGPL-3.0 and its 3.3.0 release was published on September 15, 2026. Its CMDB model is designed to be extended, which suits cardholder data environments with unusual component classes, such as payment gateways, HSM clusters or tokenization services, and their dependencies. Teams that need that modeling depth should weigh the upfront configuration effort against GLPI's more prescriptive structure.
Choosing by CMDB model depth
The right platform depends on how many CDE component types you must track and how they relate to each other. A smaller estate with standard server, network and application classes may be served well by GLPI's built-in model. A larger payment estate with custom relationships between CDE and supporting systems will usually justify iTop's extensibility. Document this decision with the assessor's scope in mind before selecting a platform.
Access controls for approvers and administrators
Requirement 6.5.4 expects separation of roles, and approvals recorded in the ITSM tool are only credible if the approver cannot also deploy the change. Check whether the platform supports role-based approval groups, step-up authentication for privileged actions and session review. GLPI 12.0.0 lists step-up authentication for certain administrative actions and a view of active sessions, which you should verify against your own role design.
Deployment and database requirements
GLPI runs on PHP with MySQL or MariaDB and offers an official Docker image among its distribution options. Confirm the supported PHP and database versions for your chosen release, and plan the hardened hosting, backups and patch cadence that the cardholder data environment will demand. Ask your partner how the platform will be placed inside the CDE boundary, or outside it, so that the ITSM system itself does not become an uncontrolled component.
Adjacent helpdesks for customer tickets only
Zammad, FreeScout and osTicket handle customer-facing support queues well, but they are not designed to hold approved change records, CMDB relationships and back-out plans for CDE components. Keep them out of the change control path unless a separate, documented process links their output to a change record in GLPI or iTop. Mixing these roles often produces approval evidence that an assessor cannot trace to a specific component.
Which evidence assessors ask for and which component produces it
This table maps each evidence artifact an assessor typically asks for under Requirement 6.5 to the ITSM component that produces it in GLPI or iTop, plus the retention question to settle before the assessment. Read it as a checklist: if a row has no named component in your configuration, that evidence will likely be assembled by hand at audit time.
| Evidence artifact | ITSM component that produces it | Retention question to confirm with the assessor |
|---|---|---|
| Change record with documented security impact | Change record with a mandatory security impact field or template section, linked to affected CIs | Does the assessor expect the impact statement in the ticket itself or in a referenced document, and for how long must closed changes stay readable? |
| Approval by authorized parties | Approval step on the change record, recording approver identity, timestamp and decision | Which roles count as authorized approvers, and must approvals be retained separately from the ticket history? |
| Pre-production test results | Linked task or attachment on the change record holding test plan, results and tester identity | Must test evidence be retained for each change or only for significant changes, and in what format? |
| Separation of environments and roles | CI environment field (production, pre-production, development) and role assignments on tasks and approvals | Does the assessor accept procedural separation for a small team, and how should exceptions be recorded? |
| Removal of test data and accounts before go-live | Checklist task on the change record with attachment of the cleanup confirmation | Which artifact proves removal (screenshot, script output, signed checklist) and how long must it be kept? |
| Post-change confirmation of PCI DSS requirements | Post-implementation review task linked to the change and to the affected CDE CIs in the CMDB | Which significant changes need a documented confirmation, and does the assessor expect it within a set window? |
| Back-out or rollback plan and execution log | Back-out plan field on the change record, with timed journal entries and the audit log of status transitions | Does the assessor need the rollback log to show actual execution, and how far back must the audit log be retrievable? |
What ITSM tooling alone does not satisfy under 6.5
A GLPI or iTop change record proves that a change was requested, approved and tracked, but Requirement 6.5 also depends on testing, secure development, role separation and scoping evidence that lives outside the service desk. The cards below name each gap and the artifact that fills it, so the assessor sees a complete trail rather than a ticket that points to nothing.
Testing happens outside the ticket
The test results that show security was not adversely affected usually come from CI/CD pipelines, staging environments and vulnerability scans. The ITSM record should link to those runs by identifier, not summarize them from memory. Check that each production change record carries a pipeline run or test report reference, and that the test environment itself meets the separation rules in 6.5.3 and 6.5.5, including removal of test data and accounts before go-live.
Secure coding evidence for custom software
Requirement 6.5.1 requires testing of custom software changes against 6.2.4, which covers common software attack types. A change ticket cannot show that developers were trained or that code review addressed those attacks. Keep secure coding records, code review logs and static or dynamic analysis reports in the repository or AppSec tooling, and reference them from the change record for each release that touches cardholder-facing code.
Role separation needs written procedure
The SAQ D note to Requirement 6.5.4 allows small teams to meet role separation with procedural controls, such as a developer using separate user-level accounts in production. The ITSM tool can record who requested and approved a change, but it cannot prove that the same person did not deploy it. Maintain a written separation policy, a list of production accounts and their owners, and periodic reviews that compare them with approval records.
Customized approach needs a documented objective
Where an entity uses the customized approach to meet a requirement, it must document the stated objective and show how the control meets it. A change workflow template cannot carry that analysis on its own. Keep a customized approach document per requirement, with the objective, the risk analysis and the test evidence, and link it from any change category that relies on it so approvers see the basis before they sign.
CDE boundary comes from scoping
Deciding which components are in the cardholder data environment depends on a documented scoping exercise that traces where account data flows and is stored. A CMDB populated by discovery shows what exists, not what is in scope. Use the scoping output to tag CI classes, data flows and network segments as in or out of the CDE, then confirm the tags against the PCI SSC significant change examples, including directory services, time servers and logging.
No tool makes a change compliant
A ticket with an approval, a test link and a back-out plan is evidence, not proof of compliance. Assessors judge whether the controls operated as described, whether changes were reviewed for security impact, and whether the people involved follow the written process. Confirm with your QSA which records they will sample, define who owns the monthly review of change records, and treat the ITSM configuration as one part of the control set.
Questions buyers ask before hiring help with PCI DSS change management
How much does PCI DSS change management work on GLPI or iTop cost?
The cost depends on the written scope, which is why DeployOpen does not publish a price list and quotes from the agreed scope. The main drivers are how many systems are in the cardholder data environment (CDE), how many integrations the change workflow needs (identity, monitoring, CI/CD, deployment tooling), how far the approval and back-out workflow is customized, and whether you need a support subscription. Some costs are one-time, such as configuration, process design and migration of existing records. Others recur, such as administration, upgrades and evidence reviews. For the platform itself, GLPI Network publishes subscription prices: 19 euros per user per month for public cloud and 21 euros per user per month for private cloud with a 25-user minimum, and self-hosted subscriptions from 100 euros per month (Basic) to 4,500 euros per month (Enterprise), according to the GLPI Network subscriptions page. Ask any partner for a quote that separates these components.
How long does a PCI DSS change management implementation take?
The timeline depends on the fixed, written scope agreed before work starts, so no general duration applies. Scope drives it through the number of CDE systems in the change process, the number of integrations, the depth of workflow customization, and how much existing change history must be reviewed or migrated. Plan the schedule around the phases the evidence requires: defining change types and approval roles, configuring the workflow, testing the back-out steps, and running a few real changes end to end before your assessor's review. Ask a partner to show the milestones, the client dependencies (such as access to identity systems and staff for approvals) and what happens if a dependency slips.
Can our own team configure GLPI or iTop for PCI DSS change control?
Yes, a capable internal team can configure the change types, approval steps, templates and reporting in GLPI or iTop. The harder part is the control design around the tool. Requirement 6.5.4 separates roles between production and pre-production, and the SAQ D note to that requirement accepts procedural controls for small teams, such as a developer using separate user-level accounts in production. Someone other than the change requester must approve and review the evidence, and that reviewer needs authority and time. Your team should also confirm whether the change workflow covers the significant-change activities listed in PCI SSC FAQ 1317, such as changes to data flows, the CDE boundary and supporting services like directory services, time servers and logging. Many organizations keep configuration in-house and bring in outside help for the design review and independent testing.
Does installing an ITSM platform make us PCI DSS compliant?
No. A platform records and enforces a process, but PCI DSS compliance covers the whole environment, including network controls, access control, logging, vulnerability management, policies and the people who follow them. The platform only supports Requirement 6.5 evidence, such as documented security impact, approvals, test results and back-out records. Compliance is determined by your assessment: a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance, according to PCI SSC FAQ 1220. DeployOpen prepares systems, controls and evidence for assessment but does not issue audit reports, attestations or certifications.
Which PCI DSS version should we design our change process against?
Design against PCI DSS v4.0.1, which is the only active version. It was published on 11 June 2024 as a limited revision of v4.0 with no added or deleted requirements, and v4.0 was retired on 31 December 2024, according to the PCI SSC blog on v4.0.1. PCI SSC ran a request for comments from 3 June to 20 July 2026 for the next iteration, but as of October 2026 it had announced no release date for a new version. Ask your assessor which version they will use for your assessment date, and build the change procedure so that requirement mappings can be updated if a future version changes the wording.
Which parts of PCI DSS change management does the implementation partner cover?
A typical engagement covers the parts that touch the ITSM platform: change types and risk criteria, the security impact field, approval routing, test evidence attachments, back-out and return-to-secure-state steps, and links from changes to CDE assets in the CMDB. It can also include reviewing whether CDE assets and their dependencies are recorded accurately, and preparing the evidence set for your assessor. Ask the partner to list in the written scope which requirements are covered, which are out of scope, and who signs off on the evidence. Testing of your application code, such as the custom software checks in Requirement 6.5.1, may need a separate security testing engagement.
What does a GLPI support subscription add beyond the software?
The GLPI Network subscription levels are described by Teclib' on its published subscriptions page, which lists agent and asset limits for the self-hosted tiers and level 3 support for the Enterprise tier. Confirm with the vendor what each tier includes, such as response times, upgrade assistance and access to marketplace plugins, and whether those terms fit your change calendar. Support does not replace your own control design, and it does not make a change record compliant on its own. Ask for the terms in writing and compare them with the support you need during a release freeze or an assessment window.
How to roll out change control in the CDE without stopping releases
The rollout adds ITSM change control to the cardholder data environment in stages, starting with agreed scope and a single release train, so each production change leaves approval, testing and back-out records that a QSA can sample. Releases continue throughout because the pilot runs on one train before the process applies to all of them.
Confirm CDE scope with the assessor
Agree in writing with your QSA or internal assessor which systems, networks, people and connected services sit inside the cardholder data environment and where the boundary runs. The owner is the compliance lead, with security architecture and the platform team providing the system lists. The step is done when the scope statement is signed off and every later CMDB entry can be traced back to it.
Load CDE systems into the CMDB
Import the in-scope configuration items into GLPI or iTop and add fields for environment (production, pre-production, test), CDE membership and boundary status, along with owner and supporting services such as directory, time and logging. The CMDB owner reconciles these records against the agreed scope list and the inventory agents' output. The step closes when every CDE asset has an owner, an environment value and a boundary flag, and unlisted systems are flagged for review.
Define significant-change categories
Write the categories that trigger a full change record and the assessor's review, drawing on the activities the PCI SSC lists as significant change in FAQ 1317, such as new CDE hardware or software, changes to data flows or storage, boundary changes and changes to supporting infrastructure. Security and change management approve the list together. The step is done when each category has a clear test, so a requester can answer whether a change is significant without asking the CAB.
Configure change templates and approvals
Build change templates in the ITSM tool with required fields for documented security impact, the approving authority, test evidence and rollback plan, then set approval workflows that match the role separation the team actually operates. Confirm with the assessor how developers and operators are separated in production, including any procedural controls permitted for small teams. The step is done when a test change cannot be closed without each mandatory field and approval recorded.
Pilot on one release train
Run the new templates and approvals on one release train for a defined set of changes, with the change manager reviewing each record for completeness and the team noting where the forms slow delivery. Adjust fields, approver groups and categories based on what the pilot shows. The step is done when pilot records meet the agreed template and the team has a short list of changes that were needed before the process was extended to other trains.
Add back-out tasks and post-change checks
Attach back-out tasks to each change record that restore the previous secure state on failure, and add post-change checks that confirm security controls still operate and that the CMDB reflects the new configuration. Engineers record the outcome in the ticket, and the change manager confirms the checks. The step is done when a pilot change has a completed back-out procedure and a post-change check result attached to the record, with no open tasks left unresolved.
Review evidence samples with the QSA
Before the next assessment, pull a sample of pilot and early production change records and walk through them with the QSA, showing approval history, test results, back-out tasks, asset links and timestamps. Record the assessor's comments and update templates or categories accordingly. The step is done when the assessor confirms the sample format is acceptable or lists specific gaps, and those gaps are tracked as ITSM changes. Confirm the assessor's preferred evidence format before you start.
What DeployOpen prepares and what remains with assessors
DeployOpen configures the ITSM platform and prepares the change evidence, but it does not validate your PCI DSS compliance. On an engagement covering Requirement 6.5, DeployOpen can install and harden GLPI or iTop, build the change workflow with approval steps, risk fields, test and back-out tasks, and link change records to CMDB items for in-scope system components. It can connect the change record to CI/CD pipelines and to the identity provider so that approvers and deployers are authenticated under separate roles. It can also document the change procedure, prepare sample evidence sets and run security testing against CDE applications, so the assessor reviews a working control rather than a diagram. None of this replaces the assessment itself. DeployOpen does not issue Reports on Compliance, Attestations of Compliance or certifications; those come from a Qualified Security Assessor or from your own completion of the applicable Self-Assessment Questionnaire.
The party that must validate is not chosen by DeployOpen or by the PCI Security Standards Council. The PCI SSC states that it does not enforce compliance, and the individual payment brands decide which entities must comply and validate and run any enforcement programs. Confirm your validation obligations and merchant or service provider level with your acquirer or payment brand before you scope the ITSM work. Also confirm with your assessor which SAQ or ROC template applies to you. Do not accept a certificate or badge from any vendor, including a consultant, as proof of validation. The PCI SSC's FAQ 1220 makes clear that certificates are not recognized as validation; the assessor reads the Attestation of Compliance and the evidence behind it.
How DeployOpen scopes, builds and supports PCI DSS change control
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including ITSM change workflows for cardholder data environment systems. The work starts with a written scope that ties each change record field to the PCI DSS 6.5 evidence your assessor will ask for.
How we scope
- Map the in-scope CDE systems, change types and approval roles that the written scope covers.
- Confirm which changes count as significant change so they route through full impact review and retesting.
- Agree which deliverables, environments and timelines apply before work starts, since engagements are fixed-scope.
How we build
- Configure GLPI or iTop change templates with fields for security impact, approver, test evidence and back-out plan.
- Link change records to CMDB items, affected components and pre-production and production environments.
- Test the workflow with sample changes, including emergency change handling, before the process goes live.
How we hand over
- Document the change procedure, role separation rules and the evidence each change record must hold.
- Provide a mapping from each PCI DSS 6.5 sub-requirement to the ITSM fields, reports and retained records.
- Train change managers, approvers and administrators so the records stay consistent after handover.
How we support
- Offer ongoing support, upgrades and reviews of change records as a retainer, if you want continued help.
- Maintain the platform, back up the database and configuration, and apply GLPI or iTop updates in a planned way.
- Prepare change evidence for your Qualified Security Assessor or internal audit, though assessors issue the assessment.
