PCI DSS applies wherever cardholder data is stored, processed or transmitted, and its cost follows scope. A VP of engineering controls the biggest lever: keep card data out of as many systems as possible. Then fund the requirements that depend on engineering work: access, patching, logging and payment page scripts.
What is the current version?
The PCI Security Council published PCI DSS v4.0.1 in June 2024 as a limited revision of v4.0. It corrected errors and clarified intent and added no new or deleted requirements. The Council also confirmed that v4.0.1 does not change the 31 March 2025 effective date for the requirements that were future-dated in v4.0, so those are now in force.
Clarifications in v4.0.1 matter to engineers. Patching within 30 days applies to critical vulnerabilities, a reversion to v3.2.1 wording. Payment page script management got applicability notes. Multi-factor authentication for access into the cardholder data environment got a note on accounts that use only phishing-resistant factors.
How do you shrink scope?
Systems that touch card data, and systems connected to them, are in scope. A constructed example: a checkout page loads a processor's hosted fields in an iframe, so card numbers never reach your servers. Your servers still affect the security of the payment page, and your assessor will ask about it, but the scope is far smaller than a design where your API receives the card number.
Techniques that reduce scope include hosted payment pages, tokenization and network segmentation that you can demonstrate to an assessor. Whether a design qualifies for a lighter validation path is decided by the Council's rules and your acquirer, so ask them before you build.
Which requirements land on engineering?
Without listing every item, the recurring work falls into four areas.
- Access and authentication. Unique IDs, strong authentication, MFA into the environment, and regular access reviews.
- Vulnerability and patch management. Inventory of components, risk ranking, timely fixes for critical issues, and secure software development practices.
- Logging and monitoring. Audit trails you can actually search, with time synchronization and review.
- Payment page integrity. Knowing which scripts load on payment pages and detecting unauthorized changes.
What do assessors find most often in engineering?
Without citing statistics, the recurring themes are consistent. Scope drift: a new service starts handling card data and nobody updates the diagram. Orphaned access: former contractors keep accounts into the environment. Patch evidence: fixes happen but nothing records the date against the vulnerability. Script sprawl: a marketing tag lands on a payment page without review. Logging gaps: logs exist but nobody reviews them or can show that they do.
Each is fixable with a standing routine. Review the data flow diagram every release, automate access removal on offboarding, link patches to tickets, put payment pages behind a script approval process and schedule log review with a named owner. Routine beats heroics at assessment time.
How to check or apply this
- Draw a data flow for card data from browser to processor. Mark every system it touches.
- Ask what happens if you remove each system from the flow, and prefer designs that remove them.
- Confirm your merchant or service provider level and validation path with your acquirer.
- Inventory third-party scripts on payment pages and decide who approves additions.
- Verify that the 31 March 2025 requirements are met and evidenced, not just planned.
- Check critical-vulnerability patch timelines against what the pipeline actually achieves.
- Retain evidence continuously for the assessor.
Safeguard's dependency scanning and software inventory can support the component and vulnerability evidence, while the assessment itself must come from a qualified assessor.
Quick check
Does using a payment processor remove PCI scope?
It reduces scope, often a lot, but does not remove it. You remain responsible for how your site integrates with the processor.
Did v4.0.1 add requirements?
No. The Council states it contains corrections and clarifications with no additional or deleted requirements.
Sources
Last reviewed: 18 October 2026.
