Requirement 3.2 is a general prohibition against storing sensitive
authentication data or SAD after authorization.
Before we look in depth at the requirements in 3.2,
let's remind ourselves about sensitive authentication data.
This is the table from the beginning of the published PCI DSS.
As you can see,
there are three elements that are defined as sensitive authentication data.
The full track data from a card,
the security code used in card-not-present transactions,
which helpfully all the PCI SSE brands have a different name for.
Okay, that's not helpful, is it?
And finally, the PIN or the PIN block.
So requirement 3.2 says do not store sensitive authentication
data after a transaction has been authorized,
and if you have stored it between receiving the data
and authorizing the transaction,
it must be securely deleted immediately after authorization.
There is one exception to this rule.
If you are a card issuer or someone who works for a card issuer and you have
a business need to retain sensitive authentication data,
you can.
There's actually separate requirements and testing
procedures for each of the three types of SAD,
which are detailed in the next three sub requirements,
but generally in each of them,
the QSA is going to look at stores of cardholder data and
look to see there's any sensitive authentication data
retained after authorization.
If the terms authorization or issuer don't mean much to you,
then I can highly recommend the first module of one of my other
Pluralsight courses; Payment Card Security,
Processing, and the PCI Standards,
because this first module covers the different stages in a
payment card transaction including authorization,
clearing, and settlements,
along with the roll of the different participants in the transaction,
including issuers and merchant acquiring banks.
The first sub requirement in 3.2 concerns track data or the
track equivalent data stored on a chip card.
If we look at the back of a payment card,
there's generally a magnetic stripe on it,
and within that magnetic stripe, if you could see the data encoded in it,
there are two tracks of data, Track 1 and Track 2.
There is information within each track, which can be stored,
but storing the entire track,
which as a whole is defined as sensitive authentication data cannot be stored.
Similarly, looking at the front,
there's the same type of track information encoded within the chip on the card,
and the requirement is simple; it is to not store
this track data after authorization.
You'll also actually hear this often referred to as mag strip data or
magnetic strip data because it came from the magnetic stripe.
The QSA is going to look at lot of system components
to try to find full track data,
as well as point-of-sale systems and sales within an individual retail premises.
They'll be looking at any systems where payment card data obtained
in customer present transactions is consolidated.
The QSA is going to pay particular attention to logging,
which is a common place to find accidentally stored
sensitive authentication data.
So it has error logs, transaction history logs,
history files, any trace files used for debugging,
and all databases.
The QSA will make sure they look carefully at database
schemas and at database contents.
Requirement 3.2 .2 concerns the card verification code
using customer not present transactions,
and again the requirement is not to store this value after authorization.
Annoyingly, and it is annoying,
the card brands that make up the PCA SSC have a different name for this code.
So you might have it referred to as the CVV2,
the CAV2, or the CVC2, but look,
it's that three-digit number that's typically printed at the end
of the signature strip on the back of the card.
Okay, apart from on American Express cards,
it's a four-digit number printed on the front of the card,
and for what it's worth, AMEX refers to this as the CID,
but it doesn't matter what it's called.
It should not be stored after the transaction has been authorized,
and to prove that it hasn't,
the QSA is going to look at all systems that may have
received these values such as web servers,
contact center systems, payment gateways,
anything involved in processing customer-not-present transactions.
They're going to pay particular attention again to trace files,
log files, error reports,
as well as looking for obvious places the card data
would've been unintentionally stored,
but also looking for places it might've been written by systems
or applications and actually nobody knew the system or
application was writing the data there.
The final sub requirement in 3.2 is the prohibition against storing
personal identification numbers or PINs after authorization.
The requirement is pretty straightforward,
not to store the PIN or encrypted PIN block after authorization.
And look.
This is pretty rare so this is mainly going to supply to banks and
perhaps some very large retailers who decrypt and re-encrypt PINs
when we're routing payment transactions,
and to some service providers.
And again,
the QSA is going to look everywhere and anywhere that they
think they may find a PIN or a PIN block.