[Autogenerated] first of all,
I'm going to look at some changes to the introductory sections of the
standard which described how the standard works.
This section defines what card data is, it describes scoping.
It describes the assessment process and lots of other
fundamental information about the standard.
But before I start to look at what has changed,
I thought perhaps I should mention what hasn't changed.
The standard is basically the same.
There are still the same 12 principal requirements you'll be familiar with.
They have slightly different names but they're the same 12
principal requirements and they each contain multiple
prescriptive requirements and testing procedures.
The introductory sections that include scoping and key definitions have
been updated but they are largely the same and there is no change in
their intent and compensating controls can still be used if you can't
meet a requirement as it is written,
thinking about the process of validation that's also largely unchanged.
You still need a qualified security assessor or an internal security assessor
who will still produce a report on compliance and attestation of compliance
and although at the time of recording this course,
they have not been released,
there will still be the self assessment questionnaires or for
smaller merchants and service providers to use,
I know that the introduction is probably the part of the
standard that many people don't read,
but honestly when it was being revised by the technical working group,
responsible for Pc DSS,
the group spent an awful lot of time on making sure this introductory
section was an improvement on the previous version and that it
explained things more clearly The definitions of primary account
number and sensitive authentication data,
Pan and Sad have been tidied up.
However,
the intent behind the standard hasn't changed but the brands in
the SSC were conscious that sometimes it was interpreted in a
way that perhaps wasn't intended.
Another language is hopefully much clearer.
The intent is still that Pc IDs is applicable wherever pan is stored,
processed or transmitted and that's always been pretty clear.
However,
if the organization doesn't process pan but there is
sensitive authentication data in the environment,
there's been some cases of misinterpretation.
Remember sensitive authentication data is pins and pin blocks track
data and the CVC two from an e commerce transaction.
The standard hopefully now makes it clear that if there's only
sad in the environment and there's no pan data,
the whole of pc IDs S doesn't apply to that environment.
Only the requirements that specifically apply to Sad are
applicable and those are in requirement three.
The requirement not to store sad after authorization and
the new one in requirement three to encrypt sad if it's
stored before authorization,
there's also the reminder in the standard now that even if you
don't process store or transmit panel Sad,
but you're being asked to comply with Pc I.
D.
S.
S because you can affect the security of cardholder data.
Some pc IDs requirements will apply to you the second and
making sure things are clear exercise that the PCs working
group spent a long time checking,
is that the standard means what it says when it uses the phrase cardholder
data and account data and references to pan and too sad.
The standard now notes that they used intentionally.
So for example, if a requirement says pan,
it doesn't mean account data and it doesn't mean
cardholder data and it doesn't mean sad.
It just means pan.
So it's very important when you're looking at a requirement to say,
what does this apply to?
Does it apply to cardholder data or does it apply just a pound on its own?
And that's now noted in the standard on page five the introductory
section to version three of P C I D s s used to talk about the
relationship between P C I D S s and P A D S s,
the payment application data security standard.
PH D S s is no more.
And therefore,
the standard now talks about the relationship between P C I D S s and the
secure software framework and that consists of the secure software standard
and the secure software lifecycle standard.
If an entity has been using software developed to the
secure software standard and that software is being
validated by a secure software standard,
assessor,
there's some requirements in pc DSS will automatically be considered to be in
place if the organization is doing in house development and that has been
assessed to the secure software lifecycle standard,
Then it can say that requirements 6.2 is in place.
All of this is detailed in appendix f at the back of the
standard and also I'd expect more guidance to come out from the
council in the next couple of years.
The section describing scoping has had some rewrites
with the intent to make it clearer,
not changing the scope of PCs CSS so if somebody tells you the
scope has changed their misreading the standard.
Firstly,
the definition of the cardholder data environment or cD has been tidied up,
It's hopefully easier to understand and it contains two elements.
Firstly there are things that store process or
transmit cardholder data and secondly,
what the standard now says is anything with unrestricted
access or unrestricted connectivity to those things that store
process or transmit cardholder data.
What it means is systems or devices that are on the same network segment.
But of course,
because of cloud computing using the phrase network
segment feels a bit old fashioned.
The Pc DSS requirements then apply to people,
processes and technology in the cardholder data environment.
And the pc headsets requirements also apply to anything that can
impact the security of the cardholder data environment,
what we used to call, connected to systems as a shorthand.
The standard.
Now references a document that you might not have read,
Which is an information supplement on scoping that was published in
2017 and actually the scoping diagram from that information
supplements now incorporated into the standard.
The key point is that there's no change in the intent of the scope of systems,
people and processes that the pc IDs requirements apply to the
intent was just to make it clearer for people to understand and for
them to be less random interpretations.
The scoping sections also got quite a lot longer.
That's because some of the explanations that were previously contained in
fake you have now been incorporated into the standard.
There are new words about segmentation and explanations that address
the question of how encrypted data can affect pc IDs s scope because
although Panic Rest has to be encrypted people have used encryption
and key management and tokenization techniques to d scope certain
parts of the environment,
relying on information in some and these have now
been incorporated into the standard.
The section in the introduction about third party service
providers which are now generally referred to as T P s P s T
P s P s has also grown in length.
But again,
that's not meant to make any change in how third party service providers have
dealt with within DSS but just like the scoping section,
information that was previously contained in fact has
been written into the standard, most notably F A Q 1312,
which was the one that made it clear that not all your third party
service providers have themselves to be pc Dss compliant and the
standard now more clearly describes what needs to happen depending on
whether a teepee sp has access to the cardholder data environment or is
running or managing in scope,
components in the cardholder data environment or whether they
could impact the security of the cardholder data environment
because many people don't read the I suspect the wording here
might come as a shock to some people.
I should also point out that brands may run specific compliance programs
that se service providers have to be pc IDs compliant,
but that's a brand rule and not part of the standard.
Now, let's talk about time frames.
You might be surprised to know that if you work for a car brand or for the P.
C.
I.
S.
See how many times you ask questions like how long is a month.
And so now within the standard,
all the time frames that are used have been defined.
What's really good in my opinion,
that the standard has tried to introduce some common sense
into recurring or scheduled requirements.
So if you have a recurring task that say has to be completed monthly
and it's not completed exactly within a month.
The standard allows some leeway if there's an obvious
process in place that will detect diagnose and re mediate
a miss task in a timely manner.
There's a common sense reason for a scheduled
requirement not happening as a one off.
That's fine.
If there are processes in place.
But it is an endemic that things are happening to schedule.
That's not fine.
The entities noncompliant until both the requirements back in place
and they're assessor is confident that the necessary procedures are
in place to prevent subsequent failures.
And actually there is now a specific way of documenting
this in the report on compliance,
which we'll talk about later alongside the definition of time frames,
such as how long a week is and how long a month is.
The standard also lists events that it considers are definitely going to be a
significant change because there are some requirements in the standard that have
to be repeated when there is a significant change.
And again,
because there's been no guidance about what is considered a significant change.
This has led to queries and inconsistent approaches between assessors.
So there's now a list of things that the PCs sc considers a significant change.
It's not exhausted,
but it is the minimum that should be considered significant by any organization.
The next section of the introduction describes the two different ways of
validating that you are compliant with the PC headsets requirement.
The first is the traditional way that we've always done it,
which is now called the defined approach.
You do what the requirement states and then the testing procedure in the
standard is what's used to validate that you have indeed met the
requirements and as with version three of the standard.
If there's a legitimate and documented business or technical
reason that you can't meet a requirement.
A compensating control can still be used.
The new in version four way that an entity Cometa requirement
is what's called the customized approach.
And we're going to look at this in more detail in a later module.
But essentially for almost every single requirement,
there's a security objective.
The customized approach objective and this will be a statement such as
malicious software cannot execute and to meet the requirement,
the organization has to say what controls it has in place to
meet the customized approach objective.
More of that later,
the standard has also changed how the testing requirements are written again,
this isn't meant to mean that the requirements will be tested in differently.
It's just meant to make the standard easier to read
in version three of the standard,
every requirement 7 90 has got to do a B and C as part of the requirement.
And the testing procedure would often say test a test
B and test see in version four.
Typically the testing procedure will often just say test all
the parts of the requirements are in place.
Essentially the assessor should just test the requirements being met.
When testing things, an assessor will do one of three things,
they will either examine things such as documents or records of things that
have happened like looking at a log or a configuration file,
they will observe people doing things like somebody creating a new
system on the network or they will observe a configuration setting or
they will observe something in environment,
something like a security camera or an access door.
And finally, they can also interview people.
The testing procedure will say which of these modalities the assessor has
to use and what they're supposed to be either observing,
examining or asking again.
This is not supposed to be a change in how the standard is assessed.
It's just a change in the language used to make it clearer for
assessors and for people who will be assessed.
There's also a revised pc ID CSS glossary of terms.
Now it is part of the standard,
rather than a separate document that no one ever found or looked
at and you can find the glossary in appendix.
G the glossary should be the first place you look when you want to
know the meaning of a term used in the standard.