[Autogenerated] You may have been surprised that I talked about
negotiation of flexibility when it comes to compliance.
But actually there are three areas where you can discuss a
compliance obligation with the person is asking you to
demonstrate your compliance.
Firstly, the deadline set for you to become compliance.
In some cases this is flexible on it could be negotiated.
That's particularly true in a merchant acquirer relationship.
Secondly,
the scope of your organizational activities that
need to comply with PC idea says,
because that maybe some parts of your technology that just
can't be made to comply with PC idea says,
Well, we'll take a really long time and then finally,
how you're going to demonstrate your compliance Now we've
talked about demonstrating compliance,
either via an on site assessment that gets you were reporting
compliance or by providing a self assessment question there.
But actually,
there are a couple more documents you can typically
provide that demonstrate your own path.
The complaints you not compliant yet,
but you're on the way because if an organization isn't able
to prove its compliance straight away,
it may be able to agree a phased approach by providing a fully funded
and on realistic project plan to achieve PC ideas.
S compliance on this will typically be based on something
called the PC ideas s prioritized approach On the protest
approach we met in the big picture.
And remember,
this progressively reduces the risk of a breach of
cardholder data as an organization works towards becoming
fully compliant with the standard.
And so, typically,
one way of negotiating with somebody who's asking to be
DSS compliant is to offer this face to poach to compliance
with with agreed deadlines.
So you know, you have a deadline of when you meet Marston one and two and three,
etcetera.
So let's take a quick closer look at that protest approach.
So when an organization starting off on its PC I journey,
completing all $300 requirement is really scary.
And so the PC I SSC produced the prioritized approach which divides all of
those 300 DSS requirements into six separate milestones.
The idea being that the requirements included in the first milestone are
going to have the largest effect to reduce the probability of a successful
criminal attack against the cardholder data.
So as an organization completes its milestone,
it progressively reduces risk while becoming increasingly more compliance.
The first milestone must own one includes requirements to get rid
of data that the organization doesn't need.
Must own.
Two.
Contains requirements to protect systems and networks.
So that's most of PC ideas s requirements 12 and also to respond to an incident.
The third milestone looked at things like patching and
secure software development so that anything that accepts
payment cards so applications, payment, cut,
accepting applications, they're secure.
Marston four is all about controlling access and monetary access,
so that's most of what's in requirements.
78 on 10 of the standard Marston five is about protecting stored cardholder.
Data on all the encryption requirements are in here.
That's that's mostly requirement three.
I've been asked on lots of occasions.
What is encryption such a low priority on?
The fact is that most organizations find encryption hard to do on on
many occasions when criminals steal encrypted data.
They also steal the decryption case at the same time.
So you get a much greater risk reduction by deleting data.
You don't need securing the perimeter and securing your
systems than you do by doing encryption badly.
The final milestone includes all remaining requirements of the documentation of
policies and procedures that's got to be in requirement 12.
The prioritized approaches really well described in the document
you could get from the PC Isis See Website,
and here you can see a page taking from a shows.
The sub requirements in requirement wanna split
between Marston's World two and six.
The documents freely available from the PC I Security Standards Council website,
as is a spreadsheet you can use to filling to show how far you
getting on on the privatized approach off Bo,
the PCs ISI created.
This prioritized approach is a way of helping organizations to focus their PC.
I journey on the requirements they're going to provide the most security first,
the card brands that then decided to use up as part
of their compliance programs,
which is wire merchant can often agree with its acquirer,
a deadline for achieving each off the prioritized
approach milestones and in some cases,
carp round rules actually allow merchants to be considered compliant enough,
but only meeting.
So the 1st 2 for the 1st 4 prioritized approach milestones.
So the advice I'm going to give toe every merchant is to
have a conversation with its acquirers say,
Hey,
joining those card brown rules based on the proctors approach they apply to me.
Can I just be compliant?
But getting to the end of milestone to for the end of milestone
for the other area where it's really appropriate for a merchant
or service provided to negotiate with whoever is that's Asselin
to comply with PC Idea, says his Where Complies With PC idea says,
doesn't really make sense from a cost perspective.
A great example of this is where organisations say some
legacy technology that would cost.
I don't know the $1,000,000 to make compliant with PC, Idea says.
But that technologies only got to your lifespan before is
going to be replaced by the organization.
In fact,
the organization might be in the process of doing the replacement already.
Typically,
the acquire is going to be asked to accept the risk of this technology on.
That might even be a whole acceptance channel on that would be excluded for a
certain time period from the merchant scope of compliance or,
if the motion could say,
get to master on one for the legacy equipment that would also work the
Merchant would need to provide a costume and sensible plan to show the
acquirer that this legacy technology is definitely going to be replaced by
a compliant solution at an agreed date.
Look, I've been involved in lots of negotiations like this.
The one piece of advice I would offer is to start with
a really realistic project plan, not one that is over optimistic.
And then, once you've got the project plan, provide updates on a regular basis.
And if there's something that is going wrong if the projects
running late engaged really early because the quarries don't
like merchants sort of say, Well, we'll get compliant on that date.
No, we missed that date.
Now we want to get compliant, maybe a year later or a year later.
So realistic Project plans and stick to it.
Finally, I want to offer some personal advice.
If you're involved in a PC I program or a PC,
I project in an organization that's been a ask to comply with PC ideas
that especially this is the first time you've done it.
On the advice is this You're not the PC I police.
You're not here to enforce the most extreme interpretation of PC
idea sets the standard on your organization.
Remember, we've got toe have two ways of looking at DSS.
There's a technical standard on a whole set of car brand rules describing
how to use that technical standard to become compliance.
There's a degree of subjectivity and how organizations comply with PCs,
Idea says.
There's a degree of subjectivity in how to interpret the standard and
also to make sure you understand the car brand rules.
So whenever there's a decision to be made,
especially what it's gonna cost a lot of money always
recommend you talk with whoever is is asking you to comply
with the standard and seek their advice on.
Then finally remember, please always be secure first and compliant.
Second,
if ever your facing a compliance decision that would weaken the
security of payment card data in your organization,
you really need to stop and think, because from a card brand perspective,
their first objective is that criminals don't steal payment card data.
It's not that everything in the world complies, the PC idea says.
In the next module, we're going to start the journey to becoming PC Idea,
says compliance, and that journey starts with what discussed in this module,
which is understanding what compliance means for your organization.