[Autogenerated] Here's the wide brain coffee retail.
Know what we looked earlier?
Let's go through it.
Looking at where cardholder data is stored and ask
you whether it can be deleted.
We discovered that date was store on the point of
sale system and on the store server.
What we need to do now is to look at how much data stored on why now.
The reason that data stored here is in case they acquire is off line in the
merchant isn't able to obtain authorization the time of sale.
That's a valuable commercial feature.
And so we probably can't stop the data storage here.
But perhaps we can restrict stories just to the store server,
and so there's no data stored on the point cell system.
We'll also want to check that data is deleted once the authorizations
received so we can minimize the date of storage in these areas and
therefore reduce the impact of a data breach.
Even though we can't completely reduce the scope of our PC.
Idea, says compliance.
We're not taking these things out of scope because they're
still gonna be processing and transmitting.
We can regis storage, reducing risk.
The same is probably true of the payment system is required to store data.
So compresses the clearing file at the end of the day on again,
or we can probably do here is make sure the date is deleted as soon as
it's no longer required keeping the amount stored.
Cardholder data smallest possible.
And now we come to a database service storing the card details for
every transaction but y break office ever made on.
We need to find out why that is.
Typically, in my experience,
there are a number of reasons why card all the data is stored in databases.
The first is to be able to track customers spending across multiple wired
brain coffee branches and use it for analytics and loyalty.
The second is that somebody thought this was a good idea,
usually for accounting purposes at one stage.
But actually nothing is done with the data,
so we need to find out why the data is stored and ask.
The question is that another way of doing this on one option could just be to
store the 1st 6 and last four digits of the card number,
along with the cardholder's name and a transaction reference
rather storing the actual whole card number.
This would probably give enough uniqueness for our loyalty
program and also be sufficient for accounts when they wanted
to check refunds or prevent fraud.
As we know from PC ideas s requirement three,
The 1st 6 and last four digits of a card number alone
are not classified as cardholder data.
So by making this change, the database server no longer stores,
processes or transmits cardholder data and so now
doesn't form part of our cardholder.
Data.
Environments, however, is still connected to the cardholder data environment,
so some PC idea says requirements will still apply.
If we wanted to totally remove the database of From the Scope of PC,
Idea says,
we would also have to install a firewall between the payment
server on the database server with a strict set of rules that
only allowed the payment served to, say,
call a stored procedure on the database server.
But that didn't allow any network connections at all to be initiated
from the database service side of the firewall.
Replacing the primary account number, or PAN by another.
Value is a common technique that organizations used to
limit the storage of cardholder data.
There are three values that are typically used to replace the pan.
The first is truncation,
where the middle six digits of the card number were
replaced by another character, typically an asterisk,
leaving the 1st 6 on the last four digits of a card number.
Actually, you don't require the 1st 6 digits,
which is the bank identification number,
then just keep the last four digits and truncate the remaining 12.
The second is hashing,
and this is where a cryptographic hash is creative
the primary account number now.
But downside of this technique is that the hash is going to be
longer than the primary account number itself,
which may require system changes because the field
size is going to be different.
Getting hashing right and secure is quite complicated.
We talk about it when we discussed Requirement three
earlier in the PC idea says Path Here, a Plural sites.
If you want to use the hash to represent a primary account number in a system,
then it's best to get advice from someone who is
skilled at cryptographic operations.
The third way of storing a different identify other
than the primary account number.
But being able to relate this to the primary account number is to use a Toko.
There are commercial token ization systems available,
which will create something that looks like a primary account number.
But that isn't a primary account number.
These air, called format preserving totalization systems token,
is ations can be one way functions.
So just like a hat, you could never get back to the primary account number.
Some token ization systems could be two way,
which means that at some stage you can turn the token back into the
primary account number if you're going to do this.
And personally, it's a technique.
I've used lots to reduce the size of a cardholder data environment.
It's quite complicated in terms of your PC ideas,
a scope and where things are connected to and what can and
can't turn tokens back into card numbers.
So again, a recommend that you consult with people have done this before.
Finally,
it is really important to remember that all of Ou Bay have replaced
the premier account number with another value,
and so now a system does not store or process cardholder data unless you also
isolate that system from the cardholder data environment,
it will be still connected to the seedy and therefore in scope
of some of PC Idea says his requirements.
Having talked about hashing token ization truncation,
I must remind you that an encrypted primary account number is still
cardholder data and systems that store encrypted cardholder data are still
in scope of all the relevant PC ideas s requirements.