Understanding the Updates to Risk Management in PCI DSS v4.0

This blog was originally published by Schellman here.

Written by David Moody, Schellman.

Formula One legend Ayrton Senna once said this about racing: “I don't know driving in another way which isn't risky. Each driver has its limit. My limit is a little bit further than others.”

It’s safe to say that payment security limits are nowhere near that of a notoriously aggressive racecar legend. Risk management in this industry is paramount, and we’ve come to know a standard for it under PCI DSS v3.2.1.

Senna said that his risk limit was further out than other drivers. Similarly, the new PCI DSS v4.0 also represents a new line on risk management, albeit in the complete opposite direction. In fact, v4.0 takes a deeper and broader approach that goes beyond just a formal risk assessment.

The new requirements will likely mean changes in this area for your organization—changes you’re wondering how to implement so that you maintain compliance.

In F1, drivers have teams of engineers that help strategize them to championships, and we want to play that part for you now.

In this article, we’ll deconstruct exactly how risk assessments will work under PCI DSS v4.0. We’ll detail what’s changed from the previous version, how to upgrade your newfangled risk assessment, and some tips for areas of focus.

This new version will mean changing your approach to a standard compliance task, but having read this, you’ll know exactly how to proceed into this new territory and see success.

Risk Assessment Changes Under PCI DSS v4.0

Of course, risk assessments aren’t a completely new concept—PCI DSS has required them for many years. Under the version we’ve all become used to, organizations were required to perform a risk assessment at least annually.

You would then use those results to help you better gauge other required controls such as vulnerability management and alert monitoring, among others.

But now, PCI DSS v4.0 is elevating risk management beyond just another control to a core competency.

Since PCI DSS has historically been a mostly prescriptive framework, this represents a fundamental change in posture. The prescriptive compliance framework asked you to meet a series of controls that it spelled out some specificity. In contrast, the new 4.0 framework is oriented more toward an “objective”-based design.

How is that different?

• PCI DSS v4.0 now requires you to have controls that meet control objectives.
• While some of these resultant controls will amount to the same prescriptive controls required under the previous versions of the PCI DSS, you will need to gauge others against your risk posture.
• It follows then that you will need to support these control designs and parameters with some level of risk analysis and even, possibly, full risk assessments.
• Where you use customized controls, this objective design mandates what it calls a “mature” level of risk management.

In short, with this new “more flexible” framework, your risk decisions and the related controls must be supported by a visible risk management process.

How to Improve Your Risk Management Processes Ahead of PCI DSS v4.0 Validation

So what does this mean for your organization and your previous risk analysis as you move forward in maintaining your compliance with the PCI DSS v4.0?

You’ll need to start ramping up your risk management framework for PCI now because this is a staff-intensive process and will take time to implement properly. Moreover, your new risk analysis or assessment process should do more than just evaluate your risks and report that. It should also:

• Identify gaps; and
• Track remediations of those gaps.

Once fully implemented, you should put the process through a few iterations. Until you have a cycle of those deliverables, it will be difficult to show that a sufficient risk management process is in place as per the PCI DSS v4.0 requirements.

As you build out your process, it’s important to note that there is no requirement for a traditional, enterprise-wide risk assessment under v4.0. While that’s a best practice in the guidelines section, what the standard asks for is “targeted risk analysis.”

Translated, that’s a formal risk analysis procedure that focuses on the objective of the requirement. You must be able to demonstrate a framework of targeted risk analyses and risk assessment procedures that address the new PCI DSS requirements.

How to Ensure Your Risk Management Framework Meets PCI DSS v4.0 Standards

But how will you ensure that your organization’s new and improved risk management processes address the relevant requirements in the v4.0 standard? We have some more tips for you.

While this is not a comprehensive list of what to do, these items do address several areas.

• You should perform risk analyses at a frequency that is commensurate with the overall dynamic landscape and risk profile of your organization. (Ironically, that will require some documented risk analysis in itself to define that frequency.)
• Anywhere a requirement asks for a “periodic” or “timely” cadence or frequency to a control, you should support that cadence with a documented risk analysis.
• Dovetail and integrate your vulnerability management procedures with risk management procedures. You can use both as a source of information on existing threats and risks.
• If you decide to adopt a “customized approach” under PCI DSS v4.0, that control will need documented risk analysis that supports it while within the parameters of your risk profile. As we mentioned above, that analysis should also address the control objective.
• Similarly, with any compensating control, there will need to be a formal, documented risk analysis demonstrating how the compensating control addresses the risks posed.
• If you do use an exception policy for controls, it needs to be consistent with your documented accepted risk levels. You may need to revamp your exception management as your upgraded risk management will further restrict the latitude for any exceptions.
• Under the Business as Usual (BAU) requirements, risk assessments are listed as a best practice for security-impacting changes which may change the scope of the environment. Ensure you use them as such.

Anything that we have not covered here insofar as other areas within PCI DSS v4.0 you will likely need to address on a requirement-by-requirement basis. But you can’t go wrong if the next time someone asks why a control works the way it does and you can provide them with a solid documented analysis for it.

Next Steps For Your Risk Management

The bottom line is that if your organization does not have a robust risk management process in place, that will have to change. It will no longer do to rock up to your PCI DSS validation the same way. You’ll need to take a deeper approach and upgrade your existing risk management and risk analysis processes to address all that v4.0 requires.

Along with improving processes, this approach also means ensuring key personnel learn these improved processes and how they work. Your people will need to be well-versed in the elements of risk and the specific factors involved ahead of your assessment under PCI DSS v4.0—that may mean new training at multiple levels becomes necessary.

As uphill a climb as it all may seem now, remember that you’ve just learned what your new risk management should do and some tips for areas of focus to get you started. The PCI SSC has allowed a generous timeline for transition, and to ease the changes even further, check out our other articles on the new standard for easy deconstructions of various new elements:

• Scoping Out Scoping Requirements Under PCI DSS v4.0
• How to Keep Legacy Systems Compliant Under PCI DSS v4.0
• A PCI FAQ: 15 Questions to Get You Started

About the Author

David Moody, FRAS is a Senior Associate with Schellman & Company, LLC. Prior to joining Schellman, David worked in various areas of IT consulting, PCI, GLBA, and FISMA assessments, public accounting, litigation support, journalism, and higher education. David is a CPA, and holds additional CISSP, CISA, QSA, and PA-QSA certifications. He has over 30 years of experience serving global clients in various industries including telecommunications, banking, financial services, construction, retail, and not-for-profit charities.