PCI DSS V2.0 Risk Assessment
The PCI SSC released an updated version of its prioritised approach earlier in May with a small number of updates to milestone setting for specific requirements. One of these requirements is 12.1.2 which has moved from milestone 6 to milestone 1. This is a significant change as it means that this requirement is now in scope for alternative programs such as VISA TIP and that a new emphasis has been placed on this requirement.
So what implications does this have for planning, executing and maintaining a compliance program to the PCI DSS standard?
It implies that a full risk assessment using a formal methodology should be the first step in starting a compliance program and the first thing to do on an annual basis in maintaining a compliance program. This is something of a departure from the more established approach of executing a gap analysis against the standard and proceeding from there. The standard mentions three specific methodologies OCTAVE, ISO 27005 and NIST SP 800-30 but allows room for others (perhaps also COBIT/ISACA Risk IT).
So what is the difference between a risk assessment and a gap analysis? The answer would be quite a bit. A gap analysis is control focused, it simply asks the question is this control implement and can it be verified. Fairly binary and easy to do and produces a view that is control centric. A risk assessment is far more subjective and quite a bit more complex. First we need to clarify what we mean by risk. In the context of PCI DSS it can probably be summarised as simply ‘an expression of the impact and likelihood of a data breach involving cardholder data’. Sounds simple enough so far?
Here is where it gets a little more complicated. First the impact will be determined by the volume of cardholder data and also if any sensitive authentication data is also present. This may vary in different parts of the network and therefore a compromise may have a different impact depending on where the compromise occurs and how far it spreads. Second the likelihood needs to take into account the threats, vulnerabilities and the effectiveness of the current countermeasures to these threats and vulnerabilities. In this case the countermeasures are the ‘controls’ in PCI DSS (yes I know they are called requirements in PCI DSS but for the rest of the universe they are called controls, i.e. they control risk).
So here is where we sync back with the gap analysis but with a twist. Rather than looking at each individual control we need to look at each individual asset or asset group. By identifying the controls that should apply to this asset or asset group and reviewing the effectiveness of the controls we can calculate a relative risk value. Based on the relative risk value we now have a new way to prioritise our program (i.e. deal with the highest risks first).
It is worth noting that in a risk assessment it is the effectiveness of the control that is evaluated. While this process introduces more subjectivity to the assessment process it also does a better job of ensuring the controls are not only fit for purpose but actually deal with an identified threat.
Recent Blogs
- Visa TIP comes the US August 16, 2011
- PCI DSS V2.0 Risk Assessment June 28, 2011
- PCI SSC issues mobile payment app guidance June 24, 2011
- Compliant in the Cloud? Sounds like a reality now! March 9, 2011
- Visa Europe - Understanding PCI DSS Merchant Training Workshop November 25, 2010
- SC Magazine - Most Influential 2010 October 22, 2010
- PCI DSS Merchant Training Nottingham UK June 29, 2010
- Clouds in the sky May 19, 2010
- PCI SSC Releases ISA Details May 8, 2010
- Visa PCI Merchant Training Zagreb April 29, 2010

Always a good job right here. Keep rliolng on through.