Sin#1 – Making Up Requirements

You talking to me?, by Ped-X-Ing

One of the most common mistakes QSAs make is to simply make a requirement out of nothing. Don’t fool yourself into thinking PCI Assessing is simply black and white judgement calls, PCI DSS is complex. In fact, as a security professional, it’s easy to take any good security practice from your brain and tell someone trying to comply with PCI DSS that it needs to be done.  For example, changing passwords on a somewhat regular basis is a practice that we all hate doing, but force our users to do anyway. Even without looking at PCI DSS—a standard that has the word “security” in its name—a QSA could tell someone to set up some kind of password rotation scheme without even thinking about how it translates to Requirement 8.5. But what if our QSA is a security professional that believes more rotation is better ((Hint: More rotation is probably not better.))? He might require a company to expire passwords monthly because he knows that PCI DSS requires rotation, but maybe can’t remember exactly how often rotation is required, so for this merchant or service provider it just became monthly.

PCI DSS only requires passwords be expired every ninety days, per Requirement 8.5.9—clearly less frequent than what this QSA just required.

While this example is a relatively basic one, you can imagine that this happens often when there are now thousands of QSAs globally and they have 250+ requirements to draw from at any given time. So how does this happen?

Check back later this week for one of the reasons, Mis-hearing the Trainer!

This post originally appeared on

Possibly Related Posts: