So given PCI DSS is just a written security standard,
like I said, 27001 is a written security standard,
what makes organizations have to comply with it?
Well,
it might surprise you to know that PCI DSS compliance
isn't generally a legal requirement.
Except in certain US states and some countries,
where they've actually incorporated PCI DSS compliance into their national laws.
If you're in one of those states or countries,
you probably know about it,
so I guess the question you're asking yourself still then,
well, you know, if it's not a legal requirement,
why do companies have to comply with PCI standards?
And the answer is really, really simple.
An organization complies with PCI DSS because somebody else has asked them to.
Let's look at this.
The card schemes or card brands such as Visa or
MasterCard say to their acquirers,
make sure that all merchants comply with PCI DSS.
The acquirers have a contract with all their
merchants that acquire card transactions,
and that contract says you must comply with PCI DSS.
Similarly,
merchants and acquirers often have contracts with third party service providers.
Hosting companies, software support companies, you know, that type of thing.
And in that contract between the merchants and their service provider,
the merchant will say to the service provider,
you must comply with PCI DSS.
And the same is true for any financial company that
acquires or issues payment cards,
they're going to have a contract with the card brands or card schemes,
but their contract with service providers will say you must comply with PCI DSS,
and so it's really simple.
The reason organizations comply with PCI DSS,
is because contractually, another organization requires them to.
So that's the who makes PCI DSS happen.
When does an organization have to be compliant?
And that's really interesting, see,
organizations are generally asked to validate they comply
with the standard on an annual basis.
So they have to demonstrate to the organization that has asked
them to be compliant that they meet all the requirements
contained in the written standard.
And they do that once a year,
but of course that doesn't actually mean that you have to
just comply with PCI DSS on one day each year and you can
forget about it for the rest of it.
You've got to be compliant every day,
but you just have to demonstrate that you're
compliant to somebody else once a year.
And the way an organization demonstrates its compliance with PCI
DSS is by providing an official PCI SSC compliance document to the
organization that asked it to comply, and it can do that in three ways.
Firstly,
it could undergo an independent assessment by a qualified security assessor,
and that assessor will produce a document called a report on compliance,
which you'll hear in PCI language called a RoC.
All the organization could perform a self-assessment,
they'd complete a paper form called a
self-assessment questionnaire which is an SAQ,
you'll also hear it referred to as a "sack",
or finally,
it could provide that same self-assessment questionnaire by completing
a web form often provided by its acquiring bank,
so it can do a report on compliance by an external auditor,
or it can do a self-assessment questionnaire.
And that's how organizations demonstrate their compliance.
But actually how do you go about becoming compliant?
So an organization that wants to become compliant
usually goes through a four-step process.
It starts off by determining the scope that PCI DSS requirements will apply to,
so that's working out which systems store,
process and transmit cardholder data, and which systems are connected to them.
The next thing it does is looks at those PCI DSS requirements
and it conducts a gap assessment to see which of the
requirements the organization already does.
Thirdly is the most vital step that a lot of organizations rush over,
but really you shouldn't.
You need to work out what the scope should be,
and what needs to change to enable an organization to
comply with all the requirements.
This is where some deep thinking needs to take place,
because by doing some good network segmentation,
by outsourcing some elements of your processing,
by changing the way that you do internal business processes,
organizations can dramatically improve both security of their cardholder data,
but also significantly reduce the cost of their compliance.
And finally after determining the desired scope and then
remediating the non-compliant requirements,
the organization's going to do its first PCI DSS assessment.
So if we consider PCI DSS as a compliance program,
the who is that the compliance requirements come from the card brands,
Visa, MasterCard, American Express, Discover and JCB,
typically pushed to their merchants by their acquirers.
And why you do PCI DSS is because it's a contractual requirement.
You evidence your compliance on an annual basis,
but of course you're compliant all year round,
and you do this by using a self-assessment questionnaire,
or a report on compliance.
So whenever someone talks about PCI DSS,
remember there are two things they could be talking about.
They could be talking about the written standard itself,
which we're going to look at in the next module in a bit more detail,
or it can be talking about compliance program.
How you demonstrate compliance, to whom,
and that's the subject of the third module.
Finally at the end of this big picture,
we're going to explore 10 really common PCI DSS myths,
that you're bound to hear,
and that are going to be really helpful for you to recognize
when you hear them so you don't make really common mistakes
that other people often fall into.