Maintaining PCI DSS Compliance as Payment Systems Change: How Application Control Helps

Application control supports PCI DSS compliance as payment systems change, with guidance on keeping software approvals enforceable through necessary updates and vendor support.

Imagine your payments team is planning to upgrade the software that processes your company’s debit and credit card payments and move it onto new servers. You want the project to go ahead, and customers still need to be able to pay while the work happens. Your team has to make sure the safeguards protecting their card data continue to meet PCI DSS requirements throughout the move and once the new systems take over.

Accepting card payments comes with security requirements the company must continue to meet. Noncompliance can lead to financial penalties or loss of the ability to accept payment cards. For a business that relies on those transactions, that puts revenue directly at risk. A card-data breach brings additional consequences: damage to customer confidence, along with the urgent work of containing the incident and investigating what happened.

Your team has to keep the protections required by PCI DSS working through the upgrade and the patches, vendor support, and system changes that follow, with evidence it can produce when asked. How do you make maintaining and documenting compliance a manageable part of running payment operations?

The Upgrade Changes What You Need to Verify 

During the migration, the old servers need to keep processing payments while the vendor of your payment software helps test the new software. Your team has to keep those systems protected and verify the safeguards on their replacements, including access restrictions and security logging. After a significant change, your team needs to verify that the protections required by PCI DSS v4.0.1 are in place (Requirement 6.5.2) and update the documentation to reflect the new environment. An assessor can review the change records and observe the affected systems to verify that work. Those checks need time in the rollout plan alongside the tests that establish whether payments will process correctly.

During testing of the new installation, the vendor of your payment software asks to install an additional diagnostic tool on the new server to check that transactions are recorded correctly. Your organization approves it for that task. Once the vendor finishes, that software may remain able to run unless existing controls remove it or restrict its use. The approval record explains why it was introduced. To show that the decision is still being enforced, your team also needs evidence of what the server permits after the installation is over.

That follow-through continues as patches arrive and suppliers return to support older systems still in service. You need a process that keeps software approvals current and enforces them as those needs change. Your team needs to be able to deploy approved updates while preventing software from running where it no longer has an approved role. Records of permitted or blocked software should show your team how those rules were applied. You need a way to determine what can actually run on your payment systems, even as the software changes.

Make Software Approvals Enforceable

Your team approved the diagnostic tool for testing, and that work is now complete. You decide it no longer has an approved role on the payment server. Application control gives your team a way to enforce that decision. After the rules on that server are updated to stop permitting the tool, the next attempt to launch it is blocked.

This is Deny by Default in practice. Applications and scripts can run only when they meet your organization’s approval rules. Software that falls outside those rules is blocked, including legitimate tools with no approved role on a particular system. Your team remains responsible for reviewing approvals and updating the rules as payment operations change.

Application control contributes to your PCI DSS program by enforcing software restrictions on your payment systems, alongside the access controls, patching, and security logging that protect card data. In the first post in this series, we explored how application control supports CMMC requirements. Similarly, your PCI DSS program needs a way to enforce software policies in daily operations.

For leadership, that enforcement belongs in the upgrade’s budget and ongoing support plan. The business needs the new software to process payments correctly, and your team needs a dependable way to keep unapproved software from running alongside it.

Keep Controls Working as Payment Systems Change

Your team can prepare application control rules while testing the next payment software update. For systems with a fixed set of functions, teams can collect the updated files’ hashes (their digital fingerprints) during testing and add the approved hashes to production policies before deployment. That brings preparation of software approvals into the release process, with the rules ready before the update reaches the payment server. Your team still needs to review the update’s security impact, approve it, and test that protections continue to work as part of the PCI DSS change process.

Those rules also reduce opportunities for malware to run on the new server. A file outside the approved rules is blocked even when it has not been identified as malicious. That complements the anti-malware protections required by PCI DSS. For the upgrade’s risk review, your team can test and explain what software the new server permits. That gives leadership a concrete basis for confidence in the controls around payment operations.

Your team can preserve the approval record and the rules applied to the server, then test that the updated payment software runs and the retired diagnostic tool is blocked. These records help demonstrate that your software restrictions are working as part of the PCI DSS checks that follow a significant change. Execution history should identify the file, who attempted to run it, when, and whether it was allowed or blocked. Your team still needs to review exceptions, investigate unexpected attempts, and configure retention.

Sustain Compliance Through the Next Change

Once the new servers are processing payments, the upgrade can come off the project list. Your responsibility for protecting card data stays with you. Patches and vendor support will bring more changes, and the business still needs those systems to process payments while meeting PCI DSS requirements.

For the next upgrade, you can agree with the payments team and vendor on which software the production systems need, when temporary approvals will end, and how your team will verify that those decisions remain enforced after deployment. Including application control in that plan makes enforcing software approvals part of what the project needs to deliver. The payments team and vendor have concrete expectations to plan around, and you have a basis for judging whether the software controls are ready. You can support the upgrade with a shared understanding of how this part of your PCI DSS program will be maintained once the project ends.