The document discusses best practices for reducing the scope of PCI compliance by addressing misconceptions and emphasizing effective techniques like network segmentation, tokenization, and encryption. It highlights the requirements of the PCI Data Security Standard (DSS) and explains the differences between tokenization and encryption, particularly in relation to PCI compliance and data protection. Additionally, the document explores how tokenization aligns with GDPR's pseudonymization requirements, providing insights on data protection by design and the legal implications for data controllers.

1. Best Practices for PCI
Scope Reduction
Thursday, January 24, 2019

2. Today’s Speakers
John Noltensmeyer
ISA, CISSP, CIPP/E/US
Privacy & Compliance Solutions, TokenEx
Trevor Axiak
QSA, CISA, ISO27001 Lead Auditor, SSCP
Director, Kyte

3. S ETTI NG TH E S TAG E
Single most important task… Scoping
Some PCI misconceptions
Assessing the scope of the scope
Encryption versus tokenisation
Cloud-based versus on-premise solutions
De-scoping ecommerce payments
Tokenisation for pseudonymisation

4. S I NG LE MOS T I MP OR TANT TAS K… S C OP I NG
“All applications that store, process, or transmit cardholder data are in scope for an entity’s PCI DSS assessment…”
Payment Card Industry (PCI) Data Security Standard, v3.2.1, Page 9
Objective – reduce the scope
• Reduce complexity
• Reduce risk
• Reduce cost
Reducing scope
• Segmenting networks
• Firewalls
• ACL
• Routers
• VLANs
• Working with tokenised/sanitised/truncated data
• Selecting most suitable entry points for client systems
• Reducing logical access to what is necessary
• Do not store data
Network Segmentation

5. S OME MI S C ONC EP TI ONS
• Encrypting data makes it out of scope
• Third parties are not my responsibility
• I do not store card data, I don’t need to be PCI Compliant
• I outsourced everything, I don’t need to be PCI compliant
• I use a hosted payment page and a PCI DSS compliant
gateway, I don’t need to be PCI compliant
• We are a small company, many requirements don’t apply
• POS devices are supplied by the bank, I don’t need to be PCI
compliant.
• I use a payment application, I need to be PA-DSS compliant
• PCI DSS does not apply to card data on paper

6. WH AT I S MY P C I S C OP E?
“Network segmentation of, or isolating (segmenting), the cardholder data environment from the
remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly recommended…”
Payment Card Industry (PCI) Data Security Standard, v3.2.1, Page 10
• The PCI DSS applies to all system components
included in or connected to the cardholder data
environment (CDE)
• The CDE consists of people, processes and
technologies that store, process, or transmit
cardholder data
• Segmentation = no connectivity
• Controlled access systems are still in scope
• Out of scope = security not reviewed = untrusted
• Encryption ≠ out of scope
Impact
security
Provide
security
Provide
segmentation
Connected
to
CDE:
Store / Process /
Transmit

7. AS S ES S I NG TH E S C OP E OF TH E S C OP E
• How many applications store, process or
transmit cardholder data (CHD)?
• Which databases support the in-scope
applications?
• Which servers make up the CDE?
• What OS’s are used (MS, UNIX, Linux, AS400,
etc.)?
• Is there segmentation between the CDE and the
rest of the network? How?
• How many entry points to the network are there?
Guidance for PCI DSS Scoping and Network Segmentation • December 2016, Page 17

8. AS S ES S I NG TH E S C OP E OF TH E S C OP E
• Is wireless technology in use on the network?
• Is CHD transmitted over wireless devices at any
point?
• Are credit card numbers stored on the POS
systems
for any length of time?
• How many data centers store, process or transmit
CHD?
• How many call centers store, process or transmit
CHD?
• Is any part of the environment outsourced?
• Are there third parties, outsourcers, or business
partners connected to the network? Guidance for PCI DSS Scoping and Network Segmentation • December 2016, Page 17

9. WH AT I S TOKENI S AT ION?
Tokenisation is the process of replacing a sensitive data element such as a credit card PAN with a non-sensitive equivalent.
Tokenisation Reduces PCI Scope
• Network segmentation can be difficult and expensive
• Tokens are not in scope for PCI DSS
• Increases the likelihood of maintaining PCI compliance
between annual assessments
Tokens Are Flexible
• Length/format preserving
• No key management unlike encryption
• Enables business as usual processes
Tokenisation Does Not
• Take you completely out of PCI DSS scope
• Make you less responsible for your data
• Help with data availability
• Stop network breaches

10. ENC R Y P TI ON V S . TOKE NI S AT I ON
What is the difference?
• Encryption - A data security measure using
mathematic algorithms to generate rule-
based values in place of original data
• Tokenisation - A data security measure
using mathematic algorithms to generate
randomized values in place of original data
Encryption alone is not a full solution
• With encryption, sensitive data remains in
business systems. With tokenisation,
sensitive data is removed completely from
business systems and securely vaulted.
Tokens are versatile
• Format-preserving tokens can be utilised
where masked CC information or masked
PII is required

11. C LOU D-BAS ED V ER S U S ON-P R EMI S E S OLU TI ONS
On Premise Tokenisation
• Limited PCI DSS scope reduction - must still
maintain a CDE
• Higher risk – sensitive data still resident in
environment
• Associated personnel and hardware costs
Cloud-Based Tokenisation
• Significant reduction in PCI DSS scope
• Reduced risk – sensitive data removed from
the environment
• Platform-focused security
• Lower associated costs – cyber insurance,
PCI audit, maintenance

12. DES C OP I NG AN EC OMMER C E S OLU TI ON
Qualifying for an SAQ A
Ecommerce or mail-order/telephone-order merchants who outsource all cardholder functions to validated
third-parties are eligible for an SAQ A or an A-EP. An SAQ A contains 22 controls compared to more than 300
for the full PCI DSS.
• Use a hosted iFrame or payments page provided by a validated service provider to capture and tokenise CHD
• Do not transmit, process or
store CHD via any other
acceptance channel
• Utilise payment services of
tokenisation provider to process
transactions
• Maintain appropriate policies
and procedures

13. DES C OP I NG AN EC OMMER C E S OLU TI ON

14. P S EU DONY MI S ATI ON
Pseudonymisation Under the GDPR
Within the text of the GDPR, there are multiple references
to pseudonymisation as an appropriate mechanism for
protecting personal data.
Pseudonymisation—replacing identifying or sensitive data
with pseudonyms, is synonymous with tokenisation—
replacing identifying or sensitive data with tokens.
Article 4 – Definitions
• (1) ‘personal data’ means any information relating to an
identified or identifiable natural person (‘data subject’);
…such as a name, an identification number, location
data, an online identifier…
• (5) ‘pseudonymisation’ means the processing personal
data in such a manner that the data can no longer be
attributed to a specific data subject without the use of
additional information, provided that such additional
information is kept separately…

15. P S EU DONY MI S ATI ON
Using Tokenisation for Pseudonymisation

16. P S EU DONY MI S ATI ON
GDPR Article How Tokenisation Can Help
Article 6 – Lawfulness of processing
6(4)(e) – “the existence of appropriate
safeguards, which may include encryption or
pseudonymisation."
If you are a data controller who has a valid reason--other than consent from the
data subject--for the processing of his or her personal data “for a purpose other
than that for which the personal data have been collected”, Article 6(4)(e)
obligates you to use “appropriate safeguards, which may include encryption or
pseudonymisation."
Article 17 – Right to erasure (‘right to be
forgotten’)
“The data subject shall have the right to
obtain from the controller the erasure of
personal data concerning him or her without
undue delay…”
Article 17 allows a data subject to request a controller delete his or her personal
data. Under Article 12(2), pseudonymization of data may provide some relief
regarding Article 17 compliance.
Article 12(2) states that, “The controller shall facilitate the exercise of data
subject rights under Articles 15 to 22… unless the controller demonstrates that it
is not in a position to identify the data subject.”
Article 25 – Data protection by design and
by default
“…the controller shall, both at the time of the
determination of the means for processing
and at the time of the processing itself,
implement appropriate technical and
organisational measures, such as
pseudonymisation, which are designed to
implement data-protection principles....”
The GDPR requires “data protection by design and by default.” Article 25(1)
specifically obligates controllers to “…implement appropriate technical and
organisational measures, such as pseudonymisation.”
Pseudonymised personal data presents a lower risk, thus possibly reducing the
number of additional security measures required to meet this obligation.
Full Solution Partial Solution

17. P S EU DONY MI S ATI ON
GDPR Article How Tokenisation Can Help
Article 32 – Security of processing
“Taking into account the state of the art,
the costs of implementation and the nature,
scope, context and purposes of processing
as well as the risk of varying likelihood and
severity for the rights and freedoms of
natural persons, the controller and the
processor shall implement appropriate
technical and organisational measures…
Article 32(1) obligates controllers as well as processors to “implement
appropriate technical and organizational measures to ensure a level of security
appropriate to the risk,” including pseudonymization of personal data.
Article 33 – Notification of a personal data
breach to the supervisory authority
Article 34 – Communication of a personal
data breach to the data subject
The GDPR specifies requirements for notification in the event of a breach of
personal data. Under Article 33(1), a controller is required to notify supervisory
authorities of a breach within 72 hours unless “the personal data breach is unlikely
to result in a risk to the rights and freedoms of natural persons.” Similarly, Article
34(1) stipulates that data subjects must be notified “when the personal data
breach is likely to result in a high risk to the rights and freedoms of natural
persons…”
When evaluating the risk posed by the data breach, the level of pseudonymization
of the data will certainly play a role. Pseudonymised data likely presents a lower
risk thus, reducing the number of additional measures required to meet this
obligation.
Full Solution Partial Solution