Another aspect of card brand compliance programs is vulnerability scanning.
So as well as asking a merchant to comply with all the requirements in PSI DSS,
just about all of the card brand compliance programs also have
this special requirement: that merchants and service providers
conduct and external vulnerability scan of their internet facing
systems on a quarterly basis.
So all of the organization's internet facing systems whether their in house,
a data center, or in the cloud,
have to be scanned by and approved vulnerability scanning vendor,
or ASV.
These approved scanning vendors are accredited and tested by the PCI SSC
and you have to contract with them so that each quarter,
they will scan your externally facing IP addresses and
produce a formal PSI ASV Scan Report,
which then as a merchant you'll need to send to your
acquiring bank or to your card scheme.
So this is completely separate from the requirement to be PSI DSS compliant.
You also have to do this ASV Scan on a quarterly basis.
But here's a small opportunity for confusion because performing
quarterly external ASV scans is also a PSI DSS requirement.
It's actually requirement 11.
2.
2 but the card brands think this is so important it is vital
to make sure that your organization doesn't present
vulnerabilities to the outside world,
that this is the only PSI DSS requirement which is actually separately
validated as part of every brand's compliance program.
Frankly,
I hope you're doing external vulnerability scans a lot
more frequently than once a quarter.
I'm often asked what would happen if an organization
is not compliant with PSI DSS.
The first thing to remember is that, and I know I keep saying this,
but PSI DSS generally isn't a legal requirement.
So a merchant that isn't in compliance with PSI DSS is in breach of its
contract with its acquiring or its merchant bank.
As a result of that breach of contract,
the merchant bank could fine the merchants,
it could theoretically terminate the merchant's ability to accept payment cards,
I've never know that to happen,
or the acquirer could charge the merchants higher acquiring fees or
also monthly charges for not being compliant.
But the greatest risk to the merchant is if the merchant
suffers a breach of confidentiality of cardholder data when it
is not compliant with the standard.
Because if a criminal steals cardholder data that isn't compliant,
the merchant will automatically be deemed to be at fault and it will most
probably suffer financial penalties from the card brand.
Now what about service providers?
Being non-compliant with PSI DSS as a service provider means that
merchants might choose not to use you as a service provider.
Additionally,
non-compliant service providers would not be able to be
listed in the list of compliant service providers
maintained by some of the card brands.
So for a service provider,
PSI DSS compliance is generally purely a contractual and a commercial decision.
The other question people commonly ask me is that happens if
I genuinely can't comply with PSI DSS?
Because sometimes there's a real business reason why an
organization can't comply with the standard.
Let's give a couple of examples.
Say you're about to replace a major item of equipment and it
would cost a lot of money to get it compliant but actually
you're about to replace it next year.
Or perhaps you've just acquired a non-compliant company or you're
about to dispose of part of your company so you wouldn't want to
make it compliant before disposing of it.
So in those circumstances,
do you think you'd ask the standard's body to change the standard for
your situation or would you ask the person or the organization who is
asking you to be compliant with the standard?
Well I guess the answer there is pretty obvious.
You'd ask the organization that is asking you to comply the PSI DSS if it
will be okay for a period for you not to become compliant.
And this is why it's really important to understand the difference
between the written standard and then somebody or an organization
using the standard in a compliance program.
Because when you need a compliance exception,
you need to ask the organization that is demanding you comply with the
standard and not the body that writes the standard.
So when you genuinely can't comply with the standard or part of the standard,
it's fine to go to the organization which is contractually
asking you to comply with the standard.
You'll need to explain why you can't comply.
You'll need to describe how in the future you will be able to comply.
You'll need to show and quantify the risk of non-compliance
because effectively you're asking an organization to accept
that risk of your non-compliance.
And then you should get their agreement in writing.
This happens a lot, this is not a non-standard thing.
Before concluding this module on compliance,
I want to briefly talk about what happens if the worst
happens and you suffer a data breach.
The best bit of advice I can give to you is this: just don't panic.
This is something that happens around the world on a regular basis.
Look,
there are lots of criminals and lots of merchants and so
criminals stealing cardholder data from merchants is
probably more common than you think.
I know for you it will be the first time and it will be a shock,
but the payment card industry is used to dealing with breaches.
So the first task is to tell your acquiring bank and the card scheme.
Their aim is to find out the card numbers that the criminals have stolen so they
can then tell the issuer of the card that it's been compromised and then that
issuer could decline any suspicious transactions.
In this way,
the overall fraud caused by the merchant's lost of
cardholder data will be minimized.
As for the merchant,
if you lost cardholder data you might be held liable for the
subsequent fraudulent use of that cardholder data.
So it's in your interest to let the issuer of the card know really quickly,
as soon as possible.
The next thing that happens,
is the merchant will be required to engage a PCI Forensic Investigator,
a PFI,
and that person will come in and they'll make sure firstly that the criminal
is no longer in the system and the breach has been closed.
Secondly, they'll confirm what the window of compromise was.
In other words,
they'll work out when the criminals first gained access to the
system and then when they were expelled from the system because
that does allow them to know all of the cards that were
potentially exposed to the criminals.
And finally,
they'll want to report how the criminals gained access to the cardholder data.
So is there a problem with the standard,
was there something that wasn't in place,
did the criminal do something we've never seen before,
and so they can either tell all the merchants or tell
the PSI SSC to change the standard.
And then finally depending on whether you were compliant
with PSI DSS at the time of the breach,
you may be subject to contractual penalties.
So to summarize what we found out in this module,
being compliant with PSI DSS is a contractual requirement
that comes from one of the card brands.
Merchants and service providers demonstrate compliance by using a
Report on Compliance or a Self Assessment Questionnaire.
Whether you can use a RoC or an SAQ is based on individual
card brand rules and that typically depends on the number of
transactions you accept each year.
An ISA or a QSA can complete a Report on Compliance and along with a PCIP,
they can help you complete the Self Assessment Questionnaire.
And finally, remember that if you have questions about your compliance,
these should be addressed to the organization that
is asking you to be compliant.
So we've looked at PSI DSS the standard and we've looked at
compliance programs based on the standard.
I hope you'll join me now in the last module of this big picture on
PSI DSS where we'll discover ten of the most common myth surrounding
PSI DSS and what the real facts are.