In this last part of the big picture,
I want to quickly dispel 10 of the most common myths
that you'll hear about PCI DSS,
because myths can often create compliance nightmares and add unnecessary costs.
The first myth you're likely to hear is that if you don't store data,
PCI DSS doesn't apply.
Well, sorry, it does.
It says in the standard, PCI DSS applies if you store,
process, or transmit cardholder data.
Secondly,
you'll often see people behaving as if PCI DSS is a legal
requirement and should be treated as such.
Well, as we found out, except in a few countries and US states,
it's not a legal requirement.
It's a contractual requirement,
and it should be viewed like any other contractual requirements.
I hear this third myth lots of times, which is,
for some reason, encrypted cardholder data isn't really cardholder data.
It doesn't count, and it doesn't need to be protected by PCI DSS.
I'm afraid that's just not true.
PCI DSS requirement 3 specifies that stored cardholder data has to be encrypted,
so encrypted data is just cardholder data stored in the correct way.
Now,
there are ways you can turn cardholder data in transit and cardholder data
that's stored into not cardholder data by using encryption,
and that's all about key management and who's got the ability to
decrypt the data and what algorithms you use.
That's a complex conversation you need to have with a QSA.
This fourth myth concerns where responsibility for PCI DSS lies.
Because it's a sort of technical standard,
it sort of tends to be given to technical teams,
but you know, compliant with PCI DSS is far more wide-ranging than that,
and it often involves changes to business processes and HR systems.
You know, the best projects I've seen have been led from finance departments.
Let me give you a really quick example.
A sports stadium wants to become PCI DSS compliant.
The technical team's plan was to buy lots of
networking and lots of security equipment,
but finance decided to buy some new card acceptance terminals.
These were ones that talked directly to the acquiring bank,
and they used something called point-to-point encryption,
which actually does take encrypted data in transit out
of the merchant's responsibility.
But they used the opportunity to upgrade their terminals
to accept contact list transactions,
and this speeded up the transactions through the bar,
and it actually provided such a large increase in sales that
the program paid for itself really quickly.
PCI DSS programs are not best led from technical departments.
Next, number five.
The sales person claims that if you just buy this
product or service or software, you can forget about PCI DSS.
Ah, well, we'd all like there to be a silver bullet, but it's never true.
It has been known that sales people exaggerate,
so view all such claims with big suspicion.
No, there is no silver bullet for PCI DSS.
Sixth, because everything is outsourced,
you don't have to do anything with PCI DSS.
Well, that's not true, either,
because the fact is you need to make sure that you've properly
outsourced it and there is nothing in your control that can
affect the security of cardholder data.
You also need to make sure that you've outsourced it to a service
provider that's validated the PCI DSS compliance to you and that's
going to keep doing that every year.
The seventh myth is really common in face-to-face merchants.
I've got compliant terminals, so I'm compliant.
Well, remember, a PCI DSS compliant thing doesn't exist,
so a terminal can't be PCI DSS compliant.
It can comply with the PCI standard for terminals,
but that's mostly about protecting pins.
So the terminal might be compliant with the PCI standard,
but you still have to make sure that you,
as an organization, comply with the requirements of PCI DSS.
Yes,
some terminals can help by reducing the number of
requirements you might need to comply with,
but they can't completely remove the need for the
organization to comply with PCI DSS.
Aw, this eighth myth is really sad.
I'm too small for the criminal to take an interest.
You know, criminals are opportunists.
They'll steal cardholder data from anywhere, even small merchants.
What's really sad is that many small merchants don't actually have the
resilience to bounce back after the cost of a forensics investigation and the
PCI DSS assessment that happen after a breach happens.
So, yup, criminals attack small merchants.
The ninth myth is funny, if it also wasn't sad.
It's when organizations believe that the annual assessment means
that they're now compliant for the next 12 months.
Well, to be PCI DSS compliant,
every requirement needs to be in place and working all the time.
The assessment is merely a snapshot that verifies that
this was true at a point in time.
An assessment is required every 12 months,
but the requirements needs to be in place every single day.
This 10th myth is a strange myth to explain.
I've seen organizations react in a really strange way when they notice a PCI
control or requirement has failed and it isn't working.
They want to report it as a breach of compliance to someone,
almost as if they broke the law and they want to confess.
You know, this is going to happen on a regular basis.
There's 280 controls to keep going every single day.
It's not like a data breach, and no one needs to be told.
Fix it, document it, and make sure it doesn't happen again.
But if you can't fix it in a reasonable period of time,
that's when you want to think about having a conversation with the
organization that's asked you to be compliant,
because now you're sort of knowingly in breach of contract.
So you want to quickly get back into compliance,
and if you can't, that's when you need to go and have that conversation.
Ha, now, like the volume control on all great systems,
my list of myths actually stops at 11, and it's this: PCI DSS is binary.
It isn't.
You know, a standard that requires a two-meter fence is absolute.
A fence is either two meters high or it's not two meters high.
But technical standards are open to interpretation.
In my experience, and I've worked in PCI DSS for seven or eight years,
people forget the risk that's involved when they
start to interpret the standard.
So when the standard's not clear,
when you've read the standard and you've read the guidance and
you've looked at the testing procedures and you're still confused
as to what would be compliant or not,
then that's the time to take a risk-based view.
Interpret the standard based on realistic risk and not a black and white,
logical interpretation of something.
If you need advice or you want to discuss how your organization
implements the standard or a particular control,
then talk to the person that's contractually asking you to comply,
and remember that will usually be your acquiring bank.
Now we've come to the end of this big picture course.
We've discovered that there are two ways of looking at PCI DSS.
It's a prescriptive standard consisting of 12 main requirements
broken down into around 280 detailed sub-requirements.
It's also the basis for compliance programs that will
contractually apply to every organization that stores,
processes, or transmits cardholder data.
There is one written standard, and there are multiple compliance programs.
I want to finish with one practical tip.
If you're working in a PCI environment, download the standard from the Internet.
Print it out, carry it around.
Refer to it and check interpretations with it.
When someone says to you, "PCI DSS requires this,
" ask which requirement they're referring to.
Look it up.
Check that it's a real requirement and not a myth or something that somebody,
in the best faith, made up.
I've seen organizations waste so much money doing things to be PCI
DSS compliant that were simply not required,
because they weren't part of the standard.