CERTIKIT PCI DSS Implementation Guide v6

PCI DSS Implementation Guide

PCI DSS Toolkit: Version 6 ©CertiKit

PCI DSS Implementation Guide

Contents 1

2

Introduction ........................................................................................................................ 4 1.1

What is Cardholder Data (CHD)? ................................................................................... 4

1.2

What is Sensitive Authentication Data (SAD)? ............................................................... 4

1.3

What is the Cardholder Data Environment (CDE)? ......................................................... 5

1.4

What role does your organization play in payment card processing? ............................. 5

1.5

Merchant and service provider levels ........................................................................... 5

Where to start ..................................................................................................................... 7 2.1

Knowing your network ................................................................................................. 7

2.1.1 2.1.2 2.1.3

2.2 3

Cardholder data flow ...................................................................................................................... 7 Identifying the Cardholder Data Environment (CDE) ...................................................................... 7 Network segmentation ................................................................................................................... 8

The prioritized approach .............................................................................................. 8

The 12 requirements of PCI DSS............................................................................................ 9 3.1

Requirement 1: Install and maintain a firewall configuration to protect cardholder data 9

3.2 Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters ............................................................................................................... 10 3.3

Requirement 3: Protect stored cardholder data .......................................................... 10

3.4

Requirement 4: Encrypt transmission of cardholder data across open, public networks11

3.5 Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs ............................................................................................................ 12 3.6

Requirement 6: Develop and maintain secure systems and applications ...................... 12

3.7

Requirement 7: Restrict access to cardholder data by business need to know.............. 13

3.8

Requirement 8: Identify and authenticate access to system components .................... 14

3.9

Requirement 9: Restrict physical access to cardholder data ......................................... 14

3.10

Requirement 10: Track and monitor access to network resources and cardholder data 15

3.11

Requirement 11: Regularly test security systems and processes .................................. 16

3.12

Requirement 12: Maintain a policy that addresses information security for all staff .... 17

3.13

Appendix A: Additional PCI DSS requirements ............................................................ 18

3.13.1 3.13.2 3.13.3

4

Shared hosting providers ......................................................................................................... 18 Entities using SSL/early TLS ...................................................................................................... 18 Designated entities supplemental validation........................................................................... 19

Submitting compliance....................................................................................................... 20 4.1

Qualified Security Assessor ........................................................................................ 20

4.2

Report on Compliance (RoC)....................................................................................... 20

4.3

Self-assessment questionnaire (SAQ).......................................................................... 20

Page 2 of 21

PCI DSS Implementation Guide

5

Conclusion ......................................................................................................................... 21

Page 3 of 21

PCI DSS Implementation Guide

1 Introduction The Payment Card Industry Data Security Standard (PCI DSS) was created by the Payment Card Industry Security Standards Council (PCI SSC) which is governed by the following Payment Brands: • • • • •

MasterCard VISA American Express JCB Discover Financial Services

PCI DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. Any organization involved in payment card processing which includes the storing, processing or transmitting of cardholder data (CHD) is usually contractually required to be PCI DSS compliant. Failure to do so could result in penalty fines to the organization.

This guide takes you through the process of becoming compliant to the PCI DSS standard. It adopts the recommended route to compliance provided by the PCI SSC which is often referred to as the “Prioritized Approach”, which is designed to advise organizations on where to start and how to reduce risk early on their journey.

It is important to note that PCI DSS compliance should not just be treated as a project, with a beginning and an end; rather the goal should be to implement the 12 requirements of PCI DSS into the organization’s ‘business as usual’ processes and procedures when handling cardholder data.

1.1 What is Cardholder Data (CHD)?

Cardholder data is the following information on credit/debit cards: • • • •

Primary Account Number (PAN) – The long 16-digit number across the card Cardholder Name – The name of the person(s) associated with the card Expiration Date – The date the card expires Service Code – A code indicating in which country or countries the card can be used

1.2 What is Sensitive Authentication Data (SAD)?

Sensitive Authentication Data is the following information on credit/debit cards: • • •

Full Track Data – Magnetic strip on the back of the card or the chip on the front of the card CAV2/CVC2/CVV2/CID – The three or four-digit value, typically on the back of the card, next to the signature section PIN/PIN BLOCK - Personal identification number entered by cardholder during a cardpresent transaction, and/or encrypted PIN block present within the transaction message

Note: This data must never be stored, even if encrypted.

Page 4 of 21

PCI DSS Implementation Guide

1.3 What is the Cardholder Data Environment (CDE)?

The Cardholder Data Environment (CDE) is comprised of the people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. System components may include network devices, servers, computing devices, and applications. Examples of people and system components within a CDE could be: • • •

A cashier attendant using a till/cash register in a shop An ecommerce website on the Internet. The web server hosting this website would be a system component A PIN Entry Device (PED, also known as a Chip and Pin Device) in a supermarket

1.4 What role does your organization play in payment card processing?

PCI DSS applies roles to each entity involved in payment card processing. It is very important you understand what role your organization plays and those of other entities you use. Such entities include: • •

•

•

•

Merchant: an entity that accepts payment cards bearing the logos of any of the Payment Brands as payment for goods and/or services Acquirer: an entity, typically a financial institution (for example, a bank) that processes payment card transactions for merchants and is defined by a payment brand as an acquirer.

Also referred to as “merchant bank”, “acquiring bank”, or “acquiring financial institution” Processor: an entity engaged by a merchant or other entity to handle payment card transactions on their behalf. While payment processors typically provide acquiring services, payment processors are not considered acquirers unless defined as such by a payment card brand Issuer: an entity that issues payment cards or performs, facilitates, or supports issuing services including, but not limited to, issuing banks and issuing processors. Also referred to as “issuing bank” or “issuing financial institution” Service provider: a business entity that is not a payment brand. However, it might be directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services, as well as hosting providers

1.5 Merchant and service provider levels All Merchants and Service Providers are categorized into different levels depending on the volume of card payment transactions the organization processes per year. There are four levels into which an organization can be categorized, with level 1 being the highest and level 4 being the lowest.

However, the volume of transactions per year that determines the categorization level of your organization also varies between the Payment Brands (Visa, MasterCard, American Express, Discover, and JCB). Therefore, it is highly recommended you confirm your organization’s transaction Page 5 of 21

PCI DSS Implementation Guide

volume and categorization level with your acquiring bank. Once you have determined your level you will know what validation methods are required for PCI DSS compliance.

Page 6 of 21

PCI DSS Implementation Guide

2 Where to start The first, and probably most important, step towards implementing the PCI DSS standard is to understand exactly where the organization stores, processes or transmits cardholder data. The objective of this is to: • • • •

Know your network Identify cardholder and sensitive authentication data Form your cardholder data environment (CDE) Securely segment your CDE away from the rest of the organization

2.1 Knowing your network •

• •

•

2.1.1

Knowing your network sounds an obvious and easy step to complete but many organizations find that, when an incident occurs, it makes them question how well they actually understand how their network is put together. There are lots of ways to ‘deep dive’ into the network and one way doesn’t necessarily fit every organization. However, below is a suggested way to start: Network Diagram – Starting with a diagram of your network helps visualise the infrastructure and focus on the key areas to investigate Data-Discovery – Implement a data-discovery methodology to identify where cardholder data is stored, processed and transmitted. Checking every bit of data is an almost impossible task without data-discovery software to assist, but without checking you will never be sure where and how the cardholder data flows through your organization Interview – Interview and shadow key business areas relevant to PCI DSS to get an understanding of how card payment processing is being completed

Cardholder data flow

Once you understand your network and the system components within it you can start to map out the flow of cardholder data around your network. This is important as it allows you to visualise your cardholder data flow and establish your Cardholder Data Environment (CDE).

2.1.2

Identifying the Cardholder Data Environment (CDE)

Remember, the Cardholder Data Environment is made up of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. Therefore, it’s important to account for all these entities when establishing the CDE. One way to achieve this is to start with the infrastructure (Network and Cardholder Data Flow Diagram) and then overlay the processes associated with taking card payments within the organization. Finally, add the people in the organization who are involved in the processes. Once you have defined the scope of your CDE then you are ready to start applying the 12 PCI DSS requirements to it.

Page 7 of 21

PCI DSS Implementation Guide

2.1.3

Network segmentation

Although not a mandatory requirement for PCI DSS compliance, often it is beneficial to segment the technical elements of the CDE away from the rest of the infrastructure. Network segmentation is the act of splitting the computer network into subnetworks with each network becoming a segment. To control and protect subnetworks, routers, switches (with appropriate Access Control List functionality) and/or firewalls are installed. From a technical perspective, the CDE will be within its own protected network segment.

Without network segmentation to separate and protect the CDE from the rest of the infrastructure using firewalls or ACLs, the organization must accept that the whole infrastructure is part of the CDE and therefore must all be compliant with PCI DSS requirements.

2.2 The prioritized approach The Payment Card Industry Security Standard Council (PCI SSC) offers a pragmatic approach to compliance by breaking down the task into six key milestones. These milestones allow the organization to prioritize the highest risks and threats first, while on its journey to PCI DSS compliance.

The PCI DSS website has more information and clear guidance on this approach. It also offers a Prioritized Approach Tool which allows the organization to perform a gap assessment, define its approach and track and report on its progress while on the road to PCI DSS compliance.

We strongly recommend that you consider using this approach. The Prioritized Approach Tool can be found within the Document Library section here: pcisecuritystandards.org.

Page 8 of 21

PCI DSS Implementation Guide

3 The 12 requirements of PCI DSS PCI DSS provides a baseline of technical and operational requirements designed to protect cardholder data. These requirements are broken down into 12 areas and we will consider each one in turn.

3.1 Requirement 1: Install and maintain a firewall configuration to protect cardholder data Relevant Toolkit Documents: • • • • • •

Network Security Policy Configuration Standard Network Diagram Example Cardholder Data Flow Diagram Example Mobile Device Policy Information Security Policy

Firewalls are essential devices that are necessary to ensure traffic flow between networks is controlled. Traditionally, firewalls were used to protect a perimeter network but it’s more common today to have segmented internal networks with firewalls controlling the traffic between them. PCI DSS recommends that you segment your CDE network to ensure cardholder data is protected. This requirement ensures there is a best practice approach to firewall security with well documented policies, procedures and configuration standards in place.

This requirement talks about ensuring a firewall and/or router are established and implemented within your organization with appropriate configuration standards in place. The main reason behind this is to provide a documented list consisting of build configuration, services installed and firewall rules. This provides you with a document to justify why a firewall or router is built in a certain way which can be used as the basis of a review against any specific firewall or router to validate its integrity. Formal processes must also be in place for effective change management.

Well thought-out firewall configurations are also part of this requirement to protect the cardholder data. Configurations include those to restrict connections from untrusted networks to the network where cardholder data is present, to restrict all traffic that is not necessary for the cardholder data environment, to implement anti spoofing measures, and to implement a DMZ (Demilitarized Zone).

Installing personal firewall software (or equivalent functionality) is also applicable to this requirement when using portable computing devices in and outside the Cardholder Data Environment. This provides additional protection to the cardholder data when the portable device is outside of the CDE and is not protected by a corporate firewall or router. This personal firewall must always be active and must not be alterable by users of the portable computer.

Finally, it is required that all security policies and procedures for managing firewalls and routers are documented, in use and known to all affected parties.

Page 9 of 21

PCI DSS Implementation Guide

3.2 Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Relevant Toolkit Documents: • • • •

Password Policy Configuration Standard CDE Asset Inventory Database Operating Procedure

Recent data breaches have shown that, even in today’s world, the use of vendor-supplied default passwords is widespread. Malicious individuals will exploit this fact to attempt to compromise your cardholder data. This requirement ensures organizations disable or change system default passwords on all system components within the CDE. Like requirement 1, this requirement also refers to configuration standards for all system components that are within the Cardholder Data Environment. Within each configuration standard it must state that system components address all known vulnerabilities and are consistent with industry-accepted system hardening standards. These include but are not limited to: • • • •

Center for Internet Security (CIS) International Organization for Standardization (ISO) Sysadmin Audit Network Security (SANS) Institute National Institute of Standards Technology (NIST)

Further security and technical controls are needed within this section to ensure the system only provides functionality to serve its purpose and nothing else. Controls include the implementation of encryption on all non-console administrative access using strong cryptography (TLS 1.2) and ensuring only those services and daemons are enabled, that are necessary to allow the correct functioning of the system.

This section also covers the need to maintain an inventory of system components within scope of PCI DSS. This is important as it ensures system administrators review all system components against configuration standards and keep the integrity of the system intact.

Finally, it is required that all security policies and procedures for vendor defaults and other security parameters are documented, in use and known to all affected parties.

3.3 Requirement 3: Protect stored cardholder data Relevant Toolkit Documents: • • •

Data Retention and Protection Policy Cryptographic Policy Information Security Policy

Protection of cardholder data by methods such as encryption, masking etc. is critical. If a malicious individual were to circumvent other security controls within your organization then, without the

Page 10 of 21

PCI DSS Implementation Guide

correct decryption keys, the data would be unreadable. This requirement sets out a baseline of cryptographic processes, policies, procedures and technology to use.

This section talks about keeping card holder data storage to a minimum i.e. if the organization does not need to store the cardholder data for legal, regulatory and/or business requirements, then the data must be safely disposed of. Implementing appropriate data retention and disposal policies ensures the card holder data is managed by specifically setting out retention dates and processes for secure deletion/disposal of the data when it is no longer required. Also, the policy should set out exactly what elements of the cardholder data should be retained. For example, an organization may need to retain one or more of the cardholder’s name, Primary Account Number (PAN), expiration date and service code.

Where there is a requirement to store cardholder data it must be kept in a secure manner using strong encryption and hashing technologies. A Cryptographic Policy must be implemented to highlight what encryption is being used and where. This ensures the organization can manage the process of encryption and decryption efficiently. Key management processes and procedures must also be implemented to ensure encryption keys are stored in a secure way with only authorized people allowed to access the keys. This ensures that keys are restricted to the fewest number of custodians necessary. Key-encrypting technologies must also be used to encrypt keys securely, so no unauthorized people can access them.

Finally, it is required that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

3.4 Requirement 4: Encrypt transmission of cardholder data across open, public networks Relevant Toolkit Documents: • • • •

Acceptable Use Policy Cryptographic Policy Data Retention and Protection Policy Information Security Policy

Working in public areas is becoming more and more common. Therefore, it is important that cardholder data is encrypted during transmission over public networks. Without effective encryption in place, a malicious individual could intercept this traffic and gain access to the data. Also, some organizations’ wireless networks may be misconfigured or have legacy equipment that potentially has vulnerabilities that are prone to attack.

This requirement ensures cardholder data is secured in transmission. To do this, strong cryptography and security protocols must always be used across open/public networks. A cryptographic policy is implemented here to describe what encryption technology is being used, how it is secured and how it is managed. It is also important to note that some protocols (such as SSL, SSH v1.0 and early TLS) have known vulnerabilities and therefore should not be used.

Finally, it is required that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.

Page 11 of 21

PCI DSS Implementation Guide

3.5 Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs Relevant Toolkit Documents: • •

Anti-Malware Policy Information Security Policy

Malware is an ever-evolving threat targeting computers, networks, software and storage devices the world over. Having anti-virus software installed on all systems to reduce this threat, whilst allowing approved business activities to continue, is important in any organization. This PCI DSS requirement sets out a baseline of processes, policies and procedures to ensure cardholder data remains secure and the threat of attack is reduced.

Deploying anti-virus software is a must for this requirement. However, it is also equally important to ensure the anti-virus software is fit for purpose, regularly reviewed and maintained, and not tampered with. To do this an anti-malware policy must be implemented, which specifies in detail how the organization manages and maintains the anti-virus software so that: • • •

The anti-virus software is actively running and kept up to date Periodic scans are complete Audit logs are retained

Finally, it is required that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties.

3.6 Requirement 6: Develop and maintain secure systems and applications Relevant Toolkit Documents: • • • • • •

Technical Vulnerability Management Policy Software Policy Change Management Process Change Request Form Technical Change Request Form Information Security Policy

Malicious individuals may use security vulnerabilities to gain access to an organization’s systems.

Many of these vulnerabilities are fixed by vendor-provided security patches, which is why it’s important to have a process in place to ensure all system patching is completed in a timely manner.

This requirement ensures software patching is documented and completed on a regular basis.

A Technical Vulnerability Management Policy is required which states how the organization intends to address vulnerabilities, including: • • •

Identifying the systems that have vulnerabilities that could be exploited.

Applying a risk ranking to vulnerabilities (for example, as high, medium or low) Stating the frequency of application of patches to the systems Page 12 of 21

PCI DSS Implementation Guide

•

Ensuring that critical updates are applied within one month of release

Organizations that create and develop their own software must ensure that the software is developed in accordance with industry standards and/or best practices. A Software Policy may be used to define how the organization achieves this. Within the policy it will state that all development is compliant with PCI DSS and considers information security in general throughout the softwaredevelopment life cycle. Custom code should also be reviewed prior to release to production to ensure the software is created using secure coding techniques.

Strict change control processes must be in place and documented to ensure safe and secure transition of software from the test to the live environment. The change control process must include consideration of impact, testing, back out plans and approval of the change. Also, the change must highlight checks to the security of the system to ensure it remains secure and in line with PCI DSS requirements. Upon completion of the change all PCI DSS-required documentation must be updated where appropriate.

Finally, it is required that all security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.

3.7 Requirement 7: Restrict access to cardholder data by business need to know Relevant Toolkit Documents • • • •

Access Control Policy User Access Management Process Change Request Form Information Security Policy

Staff members should only have access to those systems and information assets necessary to perform their job responsibilities. Enforcing this rule ensures that staff cannot accidentally or maliciously compromise cardholder data. The principle of “need to know” dictates that only those access rights needed to perform a job role are granted. This requirement ensures effective authorization is actively being used within the organization.

An Access Control Policy will need to be implemented which defines access needs for each role within the organization, along with access level, for example, user or administrator access.

Justification will be needed per role access as it is a requirement to identify appropriately secure levels of access to specific system components. This limits access to cardholder data to only those individuals whose job requires it. Documented approval of access must be given by authorized parties, which specifies the required privileges and why the individual needs them.

Finally, it is required that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.

Page 13 of 21

PCI DSS Implementation Guide

3.8 Requirement 8: Identify and authenticate access to system components Relevant Toolkit Documents • • • • • •

Password Policy Remote Working Policy Cryptographic Policy Security Awareness Training Presentation Slides Information Security Communication Programme Information Security Policy

Assigning a unique identification (ID) to each person allows an organization to control, monitor and trace access to systems and ensure that everyone is accountable for their actions. This requirement sets out a baseline of processes, policies and procedures to ensure access to cardholder data is effectively managed.

Working in conjunction with the access control policy, a password policy is required within this section. The password policy includes password complexity requirements such as: • •

A minimum length of at least seven characters.

Contains both numeric and alphabetic characters.

Also, it may specify that passwords must be changed at least once every 90 days and be different from the last four used. When actioning a password reset an administrator must ensure a temporary password is used and expiry parameters set so that the user must change their password upon first logon to the system component. This ensures that only the owner of the user account knows the password.

Multi-factor authentication must also be used when accessing the network remotely and when accessing the Cardholder Data Environment (CDE) on the internal network.

User communication and guidance on the password policy is an important and fundamental part of this requirement. Individuals must know the importance of keeping their passwords secure and must be informed about how to select strong authentication credentials. The toolkit’s Security Awareness Presentation Slides can help with this element of the requirement.

Finally, it is required that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.

3.9 Requirement 9: Restrict physical access to cardholder data Relevant Toolkit Documents • • • • •

Physical Security Policy Procedure for Taking Assets Offsite CDE Physical Access Procedure Visitor Log CDE Asset Inventory Database

Page 14 of 21

PCI DSS Implementation Guide

•

Information Security Policy

Physical access considerations within a CDE are equally as important as electronic access, as it’s sometimes the case that individuals write cardholder information down or print hard copies when they shouldn’t. This requirement ensures all appropriate controls are in place to physically secure the CDE. A Physical Security Policy must be implemented to set out how the organization approaches the security of the buildings, offices, hardware etc. that make up the Cardholder Data Environment.

Within the policy it must include what entry controls the organization must restrict access to the CDE and/or what surveillance mechanisms are in place, for example, video cameras.

Physical and/or logical controls must be in place to protect the following components: • • • • •

Network jacks in public locations Wireless access points Gateways Handheld devices Networking or communication lines

Asset management is also a key part of this requirement. Recording information such as the make, model and serial number of assets is important to be able to correctly identify them. Procedures will also need to be implemented for the protection of assets going offsite in order to keep the Cardholder Data Environment secure. Periodic inspection of assets is also required to help the organization detect tampering which could compromise cardholder data. Training on how to inspect assets will need to be provided to the appropriate individuals.

Finally, it is required that security policies and operational procedures for restricting physical access to cardholder data are documented, in use, and known to all affected parties.

3.10 Requirement 10: Track and monitor access to network resources and cardholder data Relevant Toolkit Documents • • • •

Network Security Policy Procedure for Monitoring the Use of IT Systems Security Incident Response Procedure Information Security Policy

Logging and the ability to track user activities are critical in preventing, detecting or minimizing the impact of a data compromise. This requirement sets out objectives to ensure all appropriate systems are actively logging relevant events and that these logs are being reviewed on a regular basis.

A procedure for the monitoring of IT systems must be in place which explains what is monitored, when and how, including: • • •

Unauthorised access attempts Unusual use of privileged accounts, for example, administrator Attachment of unauthorised removable media devices Page 15 of 21

PCI DSS Implementation Guide

• • •

Unusual patterns of activity, for example, late at night Changes to system settings Suspicious network activity

Audit logging is required to detect and report on the following types of events: • • • • • • •

User identification Dates and times of key events, for example, log on/log off Success and failure in system access attempts Success and failure in data and other resource access attempts (i.e. cardholder data) Changes to system parameters and configurations Use of system utilities and applications Actions taken by users with administrative privileges

A time synchronization mechanism needs to be in place to ensure all systems are synced with an industry-accepted time source. This means that, when reviewing logs, the correct time and date of an event is shown, regardless of the device involved.

Finally, it is required that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.

3.11 Requirement 11: Regularly test security systems and processes Relevant Toolkit Documents • • • • • • • • •

Technical Vulnerability Management Policy Network Security Policy CDE Asset Inventory Database Security Incident Response Procedure Risk Assessment and Mitigation Process Risk Mitigation Plan Change Management Process Procedure for Monitoring the Use of IT Systems Information Security Policy

One of the best ways to ensure the organization’s security controls are enough is to perform regular vulnerability testing. This requirement ensures that testing is completed frequently, and against industry-known best practices.

Testing is broken down into several areas below and PCI DSS requires each test to be completed at certain times annually. Areas to be tested include: • •

Internal and external vulnerability scans – to be completed at least quarterly by an approved scanning vendor (a list of these can be found on the PCI DSS website) External penetration scan at least annually or after any significant change that could affect the CDE

Page 16 of 21

PCI DSS Implementation Guide

•

Tests for the presence of unauthorized wireless access points should be completed at least quarterly

All testing should be completed based on industry accepted approaches. Any vulnerabilities found during testing should be recorded, risk rated and mitigated in a controlled manner. This process should be documented within a Risk Mitigation Plan.

Prevention and detection technologies should also be implemented to further improve security.

These technologies and the above testing should be described within a Technical Vulnerability Management Policy and a Network Security Policy.

Finally, it is required that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties.

3.12 Requirement 12: Maintain a policy that addresses information security for all staff Relevant Toolkit Documents: • • • • • • • • • • • • • • • • • • •

Information Security Policy Information Security Roles Responsibilities and Authorities Information Security Communication Program Security Incident Response Procedure Service Provider and Contracts Database Employee Screening Checklist Information Security Policy for Service Provider Relationships Service Provider Due Diligence Assessment Service Provider Due Diligence Assessment Procedure Acceptable Use Policy Risk Assessment and Mitigation Process Risk Mitigation Plan Internet Acceptable Use Policy Mobile Device Policy BYOD Policy Electronic Messaging Policy Remote Working Policy Security Awareness Training Presentation Slides PCI DSS Charter

A strong Information Security Policy underpins the organization’s ability to protect the CDE and informs all employees about what is expected of them.

This requirement covers lots of areas that are generally found in an Information Security Management System (ISMS). It covers: • • •

Information security roles and responsibilities Information security communication and training to all staff members New/Existing service provider due diligence processes

Page 17 of 21

PCI DSS Implementation Guide

• • •

Acceptable use policies Employee screening Incident response process

All the above items contribute positively to the confidentiality and integrity of cardholder data.

3.13 Appendix A: Additional PCI DSS requirements Relevant Toolkit Documents: • • • • • • • • • • •

Network Security Policy Network Diagram Example Cardholder Data Flow Diagram Example Information Security Roles Responsibilities and Authorities Risk Assessment and Mitigation Process Risk Mitigation Plan Business Impact Analysis (BIA) Process Business Impact Analysis (BIA) Tool Impact Assessment Process Problem Management Process PCI DSS Compliance Review

Dependent on the different types of entity your organization is defined as, additional requirements may need to be fulfilled. This appendix is broken down into three main areas:

3.13.1 Shared hosting providers As referenced in requirements 2 and 12 of the standard, all service providers, including shared hosting providers, must adhere to PCI DSS. In addition, hosting providers must protect each entity’s hosted environment.

3.13.2 Entities using SSL/early TLS After June 30th, 2018, all organizations using SSL or early TLS as a security control on entities within the Cardholder Data Environment (CDE) must stop using them, and later versions of TLS must be implemented (for example TLS 1.2). If your organization is currently PCI DSS compliant and is still using SSL or early TLS, a risk mitigation plan with timescales must be put in place. This will ensure the organization is taking appropriate action to remain complaint after the key date.

Page 18 of 21

PCI DSS Implementation Guide

3.13.3 Designated entities supplemental validation This section applies to organizations designated by a payment brand or acquiring bank as requiring additional validation of existing PCI DSS requirements. Examples of where these would apply could include: • •

Organizations storing, processing or transmitting large volumes of cardholder data Organizations that have suffered significant or repeated breaches of cardholder data

If the organization falls under this section, additional items are required such as a PCI compliance program owned by an accountable role within the organization. Validation of the PCI DSS scope, and assurance that the requirements are being met in business-as-usual (BAU) activities, are also needed as part of this section.

Page 19 of 21

PCI DSS Implementation Guide

4 Submitting compliance Once the organization is coming towards the end of its compliance journey you will need to start thinking about submitting the appropriate documentation to your acquiring bank. How you do this depends on a few factors, which this section covers. However, we suggest you start with contacting your acquiring bank to obtain their preferred method of submitting the compliance documents.

Some banks ask them to email you the relevant documents, whilst other offer portals to log into and upload them.

4.1 Qualified Security Assessor If your organization falls with the definition of Level 1 for Merchants and Service Providers, you are required to submit compliance documents produced by a Qualified Security Assessor (QSA). QSA companies are independent security organizations that have been accredited by the PCI Security Standards Council to validate an organization’s adherence to PCI DSS. A list of QSA companies can be found on the PCI DSS website.

4.2 Report on Compliance (RoC) Completed by a QSA and only required by Level 1 Merchants and Service Providers, a Report on Compliance (RoC) provides a comprehensive summary of all 12 PCI DSS requirements undertaken by the organization and all activities and information collected during the assessment. The report should also clearly describe how the organization validates these activities and the resultant findings.

4.3 Self-assessment questionnaire (SAQ) Depending on the level of the organization, a Self-Assessment Questionnaire (SAQ) may be all that is required to be completed and submitted. SAQs are validation tools designed to assist organizations in self-evaluating their compliance with PCI DSS. There are multiple types of SAQs corresponding to the different ways card payment processing is achieved. It is important the organization selects the appropriate SAQ(s) applicable to them.

Following section 3 of this document will give you a good idea about this, but we strongly recommend that you refer to the PCI DSS website for further information to select the SAQ(s) best applied to your organization.

Page 20 of 21

PCI DSS Implementation Guide

5 Conclusion This implementation guide has taken you through the process of making your organization PCI DSS compliant, supported by the CertiKit PCI DSS Toolkit.

Implementing and maintaining PCI DSS compliance can be a big culture change towards becoming more proactive as an organization and, with the day to day reactive pressures of delivering a product or service, it can sometimes seem daunting. However, we hope you will find that the CertiKit PCI DSS Toolkit will allow your organization to take a significant step forward on your journey.

We wish you good luck in your work and, as always, we welcome any feedback you wish to give us via feedback@certikit.com.

Page 21 of 21