A version of this article appeared on Security Boulevard. It has been updated and syndicated here.

Earlier this year, the PCI Security Standards Council revealed version 4.0 of their Payment Card Industry Data Security Standard (PCI DSS). While organizations won’t need to be fully compliant with 4.0 until March 2025, this update is their most transformative to date, and will require most businesses to assess (and likely upgrade) complex security processes, and elements of their tech stack. This is in addition to implementing role-based security awareness training and regular secure coding education for developers.

This represents a golden opportunity for companies in the BFSI space to seriously uplift their security programs, ushering in a new era of people-driven cyber resilience. 

What are the biggest challenges in getting PCI DSS 4.0-ready?

Just as an organization’s security program is all-encompassing, with intricacies that are unique to its business needs and available resources, the new PCI DSS standards cover a lot of ground. However, they reveal a pointed shift towards flexibility in approaches to meeting security requirements, and in an industry where tools, threats, strategy, and compliance measures can change in an instant, this is significant.

PCI DSS 4.0 embraces the concept that there are many ways to achieve the same goal of airtight security best practices. This is true, but it seems best suited to organizations with advanced security maturity and leaves a lot of room for error, especially for those who have not been realistic in their assessment of their true internal security maturity. Ultimately, companies must be prepared to engage in security as a continuous, evolving process, not a once-off “set and forget” exercise. A strong security culture is a must, with an organization-wide commitment to security awareness. 

And those on the code-level tools - the development cohort - they must be enabled to deliver compliant, secure software in any business environment handling digital assets and transactions. 

Are your developers prepared to deliver compliant software?

Developers sit as an integral part of reaching a state of software security excellence, and this is especially relevant to more than just token PCI DSS compliance. It is crucial that developers understand the broader picture of PCI DSS 4.0 in terms of what they can control, and integrate as part of their default approach to a software build. 

Three key areas represent the most relevant changes for the development team, and they can be broken down as follows:

• Authentication: A viable plan for access control has always been a key part of PCI compliance, however, version 4.0 kicks this up a notch in a way that will require careful implementation both internally and externally. Multi-Factor Authentication (MFA) will become standard, as will bolstered rules around password complexity and timeouts.
  
  With authentication and access control security issues now the most common likely to be faced by your average developer, it is imperative that precision training is rolled out to help them identify and fix these problems in actual code.
  
  
• Encryption & Key Management: We operate in a world where we can access some of our most sensitive information via multiple access points, such as our online banking. With this high-value data at risk, encryption and strong cryptography practices are a must. Developers have to ensure they carry up-to-date knowledge on where information is transmitted, how users can access it, and even in the event of it ending up in the wrong hands, ensuring it is unreadable by threat actors.
  
  
• Malicious Software: In the previous guidelines, security controls around software protection from malicious code were referred to as “antivirus software”, but this oversimplifies what should be a multi-layered approach shielding against far more than viruses alone. Anti-malware solutions must be applied wherever necessary, and continuous logging and monitoring are mandatory.
  
  It is also vital that developers have learning pathways that cover identifying vulnerable components, especially with most codebases relying at least in part on third-party code.

What constitutes “enough” training for developers?  

Similar to previous recommendations, PCI DSS 4.0 proposes that developers are trained “at least” annually. However, if the implication is that once a year is enough of a touchpoint for secure software creation, it is nowhere near adequate and is unlikely to result in safer, compliant software. 

Developer education should start with a foundational education in the OWASP Top 10, as well as any other vulnerabilities that are language-relevant and business-critical. This should be part of an ongoing program, with the view to continue building upon those skills and embedding security not just into software development from the start, but also into their mindset and approach to their role. In addition, roles and responsibilities must be abundantly clear to the development cohort and their managers. Security should be a shared responsibility, but it’s only fair to document expectations and ensure they can be met properly.

With the lead time available to prepare for PCI DSS 4.0 compliance, it is possible to make some significant headway into organization-wide improvements to security culture, and that is fertile ground for growing the most security-aware development cohort you’ve ever had.

‍