PCI DSS Three Year Lifecycle

On June 22, the PCI Security Standards Council announced that effective October 2010, all of the standards under its care will move to a three year development lifecycle from the current two year lifecycle we have enjoyed since the standard was originally released on December 15, 2004. I had a chance to sit down with Bob Russo (VIRTUALLY that is) and discuss some of the changes and how that affects the standard going forward.

According to Russo, the change is “a direct result of feedback from [sic] our board of advisors [sic] and participating organizations ((Quote shortened for brevity.)).”  He believes the change is “a win-win for everybody.”

In the linked press release above, the Council cites feedback from key stakeholders as the primary reason why the lifecycle was extended.  Ultimately, as with most changes, it’s a double edged sword.  Let’s break down the pros and cons!


  • Longer life cycle can allow for changes to be rolled out with most budget and rollout cycles (though the sunset of the previous standard at fifteen months may cause issues depending on when  fiscal planning occurs)
  • All standards on the same cycle allows for them to be in sync with one another
  • More time passing between revs theoretically allows for a more thoughtful approach to changes and more time to test how the standard holds up to attacks
  • Errata process allows for market- or threat-driven changes to be incorporated into the standard outside of the three-year lifecycle process, if warranted


  • The payment brands themselves are still in charge of enforcement, and can dictate the version of the standard to be used for validation (I once did a PCI DSS v1.0 validation the January immediately following PCI DSS v1.2 per the customer), so longer life cycles may or may not work and could cause confusion
  • Major changes to the standard take three years MINIMUM to be included, and may not react quickly enough to prevent specific threat vectors observed in the wild
  • Minor changes, or output from SIG activity can be inserted mid-stream, and could be disruptive to current remediation plans
  • Massive updates to all three standards promote brain drain and interpretation stumbles for the first 12-18 months after release

I understand bullets two and three somewhat contradict each other.  The point I am trying to make is that major revisions will trigger updates in budgets and IT planning, while errata probably won’t, UNLESS there is some significant findings from a SIG that causes a significant change in the standard.

There are a couple of caveats to the the change, and it won’t fully be on the new lifecycle until 2013 when the next “Dot-Zero” release will be made.  The PTS standards released earlier this year will essentially live a 3.5 year lifecycle as it aligns with the rest of the lifecycle, and all standards will be revised together in 2013.  We of course have a revision coming in a few months, and according to Russo, we will be getting “summaries of the changes throughout the summer [sic] so there will not be any surprises” later this year when it does go final.  It will be nice to get previews of the updates, even in summary form, prior to the big release.

Overall, I see this as a positive move for the standard.  The only thing not clear is is how guidance from the SIGs ends up in an errata, and how compliance to the revision would be viewed inside the lifecycle. SOME of the SIGs have great guidance that should potentially be incorporated into the standard, but as it stands today it is simply guidance.  In Chapter 11 of our book, Don’t Fear the Assessor, we discuss dealing with assessors that may be influenced by outside influences such as guidance released by a SIG.  It’s still just that… guidance.

Remember, the Standard is the stone tablets by which you are measured.

This post originally appeared on BrandenWilliams.com.

Possibly Related Posts: