COMMENTARY: Organizations treat the
Payment Card Industry Data Security Standard (PCI DSS) standard as a checklist exercise, while missing the fundamental security improvements it was designed to achieve.
PCI DSS touches nearly every business that processes credit card transactions, yet most organizations approach it with the enthusiasm of filing tax returns.
[
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
Even as PCI DSS v4.0 introduces more flexible, outcome-based requirements designed to integrate with modern development practices, the uncomfortable truth remains: companies spend millions on compliance programs that deliver certificates, rather than security improvements.
Walk into any enterprise IT department during audit season, and there’s a familiar scene: Security teams scramble to document processes, development teams pause deployments to avoid “scope creep,” and everyone holds their breath until the assessor signs off. Three months later, the same vulnerabilities that existed before the audit are still there—they were just deprioritized to get fixed in a later date.
This isn’t compliance; it’s compliance theater. And it’s failing both businesses and the consumers whose payment data these standards were designed to protect.
When quarterly scans meet daily deployments
Modern software development moves at a pace that traditional compliance frameworks struggle to accommodate. Organizations deploy code multiple times per day, introduce new dependencies continuously, and operate in cloud environments that shift faster than conventional security assessments can track.
PCI DSS v4.0, which became mandatory for all its requirements on March 31, 2025, was specifically designed to address this disconnect. The updated standard introduces customized implementation approaches, emphasizes continuous monitoring over periodic checks, and supports integration with
DevOps workflows.
Yet, despite these improvements, most organizations continue operating under the old paradigm.
Consider a typical e-commerce company running dozens of microservices across multiple cloud regions: Their development teams push updates several times daily, each potentially introducing new dependencies and attack surfaces. Under the old compliance model, their program would operate on quarterly vulnerability scans and annual penetration tests—a cadence that made sense when applications were monolithic and changes were infrequent.
The math simply doesn’t work with traditional approaches. By the time vulnerabilities are identified through conventional scanning cycles, new ones have already been introduced. Even though PCI DSS v4.0 now supports more dynamic, risk-based testing and continuous monitoring, many organizations remain trapped in the old cycle of periodic assessments and perpetual technical debt.
This speed mismatch creates an impossible remediation challenge. Organizations typically take two to five months to fix vulnerabilities, while industry studies consistently show only 13% of identified issues are evert remediated, with an average remediation time of 271 days.
Meanwhile, daily deployments introduce new risks faster than teams can address existing ones. The problem intensifies when considering that 70-90% of modern application code consists of open source components, each carrying potential vulnerabilities that can emerge without warning.
When a critical flaw surfaces in a widely-used library, organizations face the stark choice between immediate emergency patching—disrupting their deployment pipeline—or accepting known risk while maintaining their release schedule. This fundamental tension between development velocity and security remediation reveals why quarterly assessment cycles cannot adequately protect systems that evolve by the hour.
The penalty of perfectionism
PCI DSS demands comprehensive vulnerability management, but the standard doesn’t account for the practical limitations most organizations face. Development teams are measured on feature delivery, not security remediation. Security teams lack the development expertise to fix complex dependency issues. The result: a growing backlog of documented vulnerabilities that everyone acknowledges but nobody can realistically address.
We’ve seen organizations maintain spreadsheets with thousands of open vulnerabilities, each carefully categorized and risk-assessed, yet with remediation timelines stretching years into the future. The documentation exists to satisfy auditors, but the underlying security posture remains fundamentally unchanged.
This creates a perverse incentive structure where compliance becomes disconnected from security outcomes. Teams optimize for audit readiness rather than risk reduction, investing more effort in justifying why vulnerabilities can’t be fixed than in actually fixing them.
The perfectionist approach reaches its logical extreme in PCI DSS 4.0’s mandate for remediating high- and critical-severity vulnerabilities within 30 days—a deadline that exemplifies compliance frameworks’ disconnect from operational reality.
In modern software stacks overwhelmingly dependent on open source components, this timeline doesn’t make sense, it’s rarely achievable. Fixing vulnerabilities in third-party libraries often requires upgrading to newer versions, potentially introducing breaking changes that cascade across the entire codebase.
Teams find themselves trapped between an unforgiving compliance mandate and operational feasibility, contributing to the very vulnerability backlogs that the strict timelines were meant to prevent. The pursuit of perfect compliance timelines, ironically, encourages the documentation of failure rather than the achievement of security.
Break the assessment-remediation deadlock
The traditional approach to PCI DSS compliance assumes that identification automatically leads to remediation. In practice, the gap between these two activities has become a chasm that most organizations can’t bridge with existing tools and processes.
PCI DSS v4.0 represents a significant step forward, introducing targeted risk analyses, enhanced vulnerability management requirements, and support for customized approaches that acknowledge operational constraints. The standard now explicitly supports continuous security processes and integration with modern development workflows—precisely the improvements the industry has needed.
Yet, the technology to implement these approaches at scale has only begun to emerge. Organizations need tools that can address vulnerabilities without forcing complex upgrade decisions or requiring specialized security expertise from development teams. The industry should maintain compliance as a byproduct of normal operations, not as a separate, disruptive process.
The challenge has been rooted in what developers call “dependency hell”—the cascading complexity that emerges when fixing one vulnerability requires upgrading components that may destabilize the broader system.
Traditional remediation efforts can trigger a domino effect of compatibility issues, especially with unsupported or end-of-life open source components that no longer receive vendor patches. This technical reality makes PCI DSS 4.0’s 30-day remediation window nearly impossible to meet through conventional approaches, leading many teams to defer updates indefinitely rather than risk system instability.
Some forward-thinking companies are breaking this deadlock by adopting approaches that deliver security patches independently of broader system upgrades, which lets them address vulnerabilities immediately rather than queuing them behind complex dependency updates or system migrations. These options represent the future of compliance: where security fixes become routine maintenance rather than architectural decisions.
PCI DSS compliance should enhance security posture, not just demonstrate it exists on paper. This requires rethinking how organizations approach the standard’s requirements, particularly around continuous vulnerability management.
Rather than treating PCI DSS as a periodic hurdle to clear, organizations should build sustainable security practices that scale with their development velocity. This means implementing automated remediation capabilities, integrating security requirements into development pipelines, and measuring success based on actual risk reduction rather than documentation completeness.
The most effective compliance programs we’ve observed share common characteristics: they minimize manual processes, integrate seamlessly with existing development workflows, and focus on outcomes rather than activities. These organizations treat PCI DSS requirements as minimum security baselines rather than maximum compliance targets.
Looking ahead, the organizations that will succeed in both security and compliance are those that fully embrace the flexibility that PCI DSS v4.0 now offers. The updated standard consists of the framework: what’s needed now are implementation approaches that stop accepting the traditional trade-offs between operational velocity and vulnerability management.
For too long, we’ve accepted that PCI DSS compliance means choosing between perfect security and operational reality. The evolution to v4.0 proves that it’s possible to change—now it’s time for organizations to demand tools and approaches that deliver on that promise of integrated, continuous security.
Itamar Sher, chief executive officer, Seal Security
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
