The PCI DSS Standard

On this post we will present an introduction to the PCI DSS Standard, what it is, what constraints it imposes for organizations, and why it matters.

What is the PCI DSS?

The acronym stands for Payment Card Industry Data Security Standard. It is a set of rules for organizations involved in processing of online payments cards which constraints the way payment card data is stored and transferred, with the goal of protecting customer data.

All merchants looking to accept card payments must comply with the standard in order to operate in the industry.

You may have noticed that the expression PCI DSS Standard is redundant, since the last S of the acronym already stands for the word Standard. From now on we will refer to it simply as PCI DSS.

The PCI DSS is written and maintained by the PCI Security Standards Council (PCI SSC). According to their website, the council was was founded in 2006 by American Express, Discover, JCB International, Mastercard and Visa Inc. They share equally in ownership, governance, and execution of the Council’s work.

Who does the PCI DSS apply to?

The PCI DSS applies to all entities that process, store and / or transmit cardholder data.

Note that this means that even if an organization doesn’t store the data and only passes it along to an external provider, the organization must still comply with PCI DSS (although the compliance process would be greatly simplified in this case). This is still valid in particular if the data that the organization processes, stores and / or transmits is a token and not a clear credit card number (see below for the concept of token).

What does PCI DSS mean for merchants?

There are several reasons why complying with PCI DSS is beneficial for businesses:

• To protect the data of your customers. Implementing good security practices reduces the likelihood and impact of a potential breach.
• Many acquiring banks demand the merchant be PCI DSS compliant in order to process credit card payments for them.
• Many acquiring banks apply a fine to non-compliant merchants.
• If a breach happens, the business may receive fines and lawsuits from customers and other organizations. Fines may come for example from credit card networks or the government. Complying with PCI DSS helps reduce these fines.

Terminology

Before we can get into the standard requirements themselves, we need to lay down some terms:

Primary Account Number (PAN)

The credit card number visible on the front of the card.

According to the rules of the PCI DSS, the PAN can be stored but in that case it must be rendered unreadable via some mechanism like for example encryption or tokenization.

Cardholder data (CHD)

This category contains the following items:

• Primary Account Number.
• Cardholder Name.
• Expiration Date.
• Service Code.

Sensitive Authentication Data (SAD)

This term includes:

• Card verification code, also known as Card Verification Value (CVV), Card Security Code (CSC).
• Full track data (magnetic-stripe data or equivalent on a chip).
• PINs/PIN blocks.

SAD like the CVV cannot be stored after the authorization completes, even if encrypted.

Cardholder Data Environment (CDE)

The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data, and any other systems that don’t but are on the same network as or have unrestricted connectivity to them.

Note the detail about unrestricted connectivity. A component that can connect to another component that stores, processes, or transmits CHD or SAD because there is a firewall rule that enables it is not part of the CDE. Such a component is part of what is called the connected-to systems (more on this below in the section about Scope).

It should be noted that systems outside of the CDE may still be relevant to a PCI DSS assessment, if they can connect to systems within the CDE (see concept of scope below).

Index Token

A non-sensitive replacement for the PAN, stored in a secure index that allows recovering the PAN (a sensitive value) from the token.

Scope

In the context of PCI DSS, the scope is the set of system components, people and processes that need to be included in the PCI DSS assessment. The first step of an assessment is to properly identify the scope of the review.

It’s important to understand that this doesn’t only involve the CDE. The PCI DSS scope is composed of:

• The CDE.
• Any system components with connectivity to or from the CDE. This category is sometimes referred to as “Connected-to” components.
• Any system that can impact the security or configuration of the CDE (e.g. a host that cannot connect directly to the CDE but can access the CDE via a jump host). This category is sometimes referred to as “Security impacting” components.

Note that a workstation that cannot connect to the CDE but can log into it via a jump host (also known as bastion host) is not in the “Connected-to” category, but is still in the “Security impacting” components and therefore in scope.

Systems that while outside of the CDE have connectivity to or from the CDE or can impact the security of the CDE are impacted by PCI DSS and this need to be secured. It is common for attackers to target systems outside of the CDE which have been considered of low importance and use them to gain access to systems inside the CDE.

A note about alternative terminology. The components in the CDE are sometimes referred to as “Category 1”. The components in the “Connected-to” and the “Security impacting” groups are sometimes referred to as “Category 2” components, and components that are not in scope are also referred to as “Category 3”. The terms “Category 1”, “Category 2” and “Category 3” are not part of the standard but they are used in part of the literature.

The following figure illustrates the elements that compose the scope in PCI DSS:

PCI Compliance process

Given an organization that processes, stores or transmits cardholder data, the process for certifying as PCI compliant involves three main elements:

• Handling the ingress and transmission of cardholder data securely.
• Storing cardholder data securely, which involves complying with the 12 requirements of PCI DSS about aspects like encryption and security testing.
• Doing annual validations that the required security controls are in place. This can include forms, questionnaires and / or external audits.

In the following sections we will present an overview of the steps involved in PCI compliance.

Step 1: Determine your requirements

The requirements of the PCI DSS vary depending on the scale of the organization. There are four different Compliance Levels:

• Level 1: Merchants that annually process over 6 million transactions of Visa or Mastercard, or more than 2.5 million of American Express, or have experienced a data breach, or are considered Level 1 by any card network (e.g. Visa, Mastercard).
• Level 2: Merchants that process 1 to 6 million transactions annually.
• Level 3: Merchants that process 20,000 to 1 million online transactions annually, or that process less than 1 million total transactions annually.
• Level 4: Merchants that process fewer than 20,000 online transactions annually, or that process up to 1 million total transactions annually.

Level 1 merchants require:

• Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) – also commonly known as a Level 1 onsite assessment – or internal auditor if signed by an officer of the company. The assessor works on site reviewing documentation artifacts, evaluating the scope of the assessment and providing support along the compliance process. The assessor submits the ROC to the organization’s acquiring banks indicating its compliance.
• Quarterly network scan by Approved Scan Vendor (ASV).
• Attestation of Compliance (AOC) for Onsite Assessments.

For organizations in levels 2 to 4, compliance requires:

• Annual PCI DSS Self-Assessment Questionnaire (SAQ) – There are nine different forms of SAQs, so the organization needs to figure out which one to use.
  • For more details about which SAQ applies to each scenario, see Stripe’s guide on PCI compliance, SAQ Instructions and Guidelines and the FAQ about using the SAQ eligibility criteria to determine onsite assessment requirements..
• Quarterly network scan by Approved Scan Vendor (ASV).
• Attestation of Compliance (AOC) – each of the 9 SAQs has a respective AOC form.

In addition to the above, the PCI SSC updates the standard every three years and releases incremental updates throughout the year, which also contributes to the complexity of the process.

Step 2: Map your data flows

This step involves identifying every application or system component where CHD is processed, transmitted or stored. This may require creating new diagrams or design artifacts, showing details like which network connections carry clear credit card numbers, which carry only tokens and which carry neither of those things.

In other words, you delineate the PCI DSS scope.

This is team effort that requires collaboration across the organization.

Step 3: Check security controls and protocols

Once you have defined the scope, you need to check every system component in it to ensure the right security configurations and protocols are in effect according to the 12 requirements of the PCI DSS.

Step 4: Monitor and maintain compliance

Once you have achieved compliance with the standard, you will need to set up a regular process to monitor and ensure that you stay compliant across changes in the organization and the standard requirements.

Depending on the scale of the organization, this may involve submitting quarterly or annual reports, and may go as far as performing annual on-site assessments.

For more information about PCI compliance process, see Prioritized Approach for PCI DSS and FAQ about requirements for merchants that develop applications for consumer devices that accept payment card data..

Segmentation

Segmentation is the act of isolating the CDE from the rest of the organization’s network, for example via a firewall. Segmentation is not a requirement of PCI DSS, but it is strongly recommended to reduce the:

• Scope of the PCI DSS assessment.
• Cost of the PCI DSS assessment.
• Complexity of implementing PCI DSS controls.
• Risk of payment data compromise.

It’ s important to understand that if segmentation is not in place, the entire network is in scope for PCI DSS.

The separation of components into different networks is not enough to qualify as segmentation. Segmentation is achieved by having controls in place to enforce separation and preventing the out of scope network from being able to access CHD.

Segmentation example

As an example, consider the following problem, from Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation:

• Design a segmented network architecture that provides an administration workstation in the corporate LAN, that enables administrative access to the CDE while also keeping the rest of the corporate LAN out of the scope of PCI DSS.

A possible solution to this problem is illustrated by the following figure:

The solution consists of the following elements:

• The system is segmented into three networks:
  • One network for the CDE (protected by a firewall).
  • One network for components that are unrelated to CHD processing (the corporate LAN).
  • One network for services which are used by both the corporate LAN and the CDE (the “shared services” network).
• A “jumpbox” (also commonly referred to as bastion host) is installed in the shared services network.
• Connection to the CDE from the corporate LAN is denied. Only the jump host can connect to the CDE.
• Connections from the admin workstation to the jump host are only allowed for designated users.
• (Other security controls required in order to comply with PCI DSS requirements, not shown here).

With the above setup, the PCI DSS scope consists of:

• The CDE.
• The shared services network.
• The jump box.
• The administration workstation.

All the other components within the corporate LAN are out of scope.

Tokenization and scope

It is clear that system components that handle PAN are part of the CDE. But what about components that only handle tokens? It depends: components that only handle tokens are considered outside the CDE as long as they are properly isolated from the CDE.

Note that even if a component that only handles tokens is outside of the CDE, that doesn’t mean that it is not in scope: it may still be in scope if it connects to a component in the CDE.

In general the use of tokenization is recommended as a way to reduce the scope and simplify the compliance process, but it does not eliminate the need to comply with PCI DSS. From, Information Supplement: PCI DSS Tokenization Guidelines:

“Tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance, but they may simplify a merchant’s validation efforts by reducing the number of system components for which PCI DSS requirements apply”.

PCI DSS and cache engines

If the set of components in scope include a cache service, we need to ensure that the cache is PCI DSS compliant. This makes the choice of cache engine relevant. This should be taken into account when designing the architecture of the system.

As an example, if we use one of the hosted cache solutions provided by the AWS Elasticache service, we have two choices of engine: Redis and Memcached. The Elasticache Redis service is PCI DSS compliant, whereas Elasticache Memached is not.

PCI DSS requirements

The following is a summary if the requirements that PCI DSS establishes. While we have included the 12 requirements, the details we mention for each are only an overview and should not be taken as an exhaustive description. For the detailed description see the actual PCI DSS test in the sources.

Requirement 1: Build and Maintain a Secure Network and Systems

This requirement consists of the following sections:

• Processes and mechanisms for installing and maintaining network security controls are defined and understood.
• Network security controls (NSCs) are configured and maintained.
• Network access to and from the cardholder data environment is restricted.
• Network connections between trusted and untrusted networks are controlled.
  • This involves among other things ensuring that the components where cardholder data is stored are not directly accessible from untrusted networks.
• Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

Requirement 2: Apply Secure Configurations to All System Components

This requirement consists of the following sections:

• Processes and mechanisms for applying secure configurations to all system components are defined and understood.
• System components are configured and managed securely.
• Wireless environments are configured and managed securely.

Example recommendations:

• Change all default passwords.

Requirement 3: Protect Stored Account Data

This requirement consists of the following sections:

• Processes and mechanisms for protecting stored account data are defined and understood.
  • Storage of account data is kept to a minimum.
• Sensitive authentication data (SAD) is not stored after authorization.
  • For example the CVV of a credit card cannot be stored after the authorization has completed, even if encrypted.
  • SAD that is stored prior to completion of the authorization must be encrypted using strong cryptography.
  • Note the category of SAD contains the CVV, but not the PAN or the expiration date.
  • To the effects of this rule, the authorization is considered to be complete when the merchant receives a response (for example approval or decline).
• Access to displays of full PAN and ability to copy cardholder data are restricted.
  • The PAN must be masked when displayed (such as in UI or logs). The BIN and the last four digits are the maximum number of digits than can be displayed.
• Primary account number (PAN) is secured wherever it is stored.
  • PAN is rendered unreadable anywhere it is stored by using any of the following approaches:
    • One-way hashes based on strong cryptography of the entire PAN.
    • Truncation, as long as hashing cannot be used to replace the truncated segment of PAN.
      • If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls must be in place such that the different versions cannot be correlated to reconstruct the original PAN.
    • Index tokens.
    • Strong cryptography with associated key management processes and procedures.

• Cryptographic keys used to protect stored account data are secured.
• Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key life cycle are defined and implemented.

Example recommendations:

• Try to avoid storing the PAN if at all possible. If you must store it, it must be encrypted.
• Try to avoid storing the CVV at all. If you must store it it can only be stored during the authorization and not after that.
• Avoid putting PANs and CVVs in logs.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

This requirement consists of the following sections:

• Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.
• PAN is protected with strong cryptography during transmission.

Requirement 5: Protect All Systems and Networks from Malicious Software

This requirement consists of the following sections:

• Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.
• Malicious software (malware) is prevented, or detected and addressed.
• Anti-malware mechanisms and processes are active, maintained, and monitored.
• Anti-phishing mechanisms protect users against phishing attacks.

Requirement 6: Develop and Maintain Secure Systems and Software

This requirement consists of the following sections:

• Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
• Bespoke and custom software are developed securely.
  • This involves ensuring that software development personnel working on bespoke and custom software are trained at least once every 12 months.
  • Software goes through a code review process prior to being released into production or to customers, to identify and correct potential coding vulnerabilities.
• Security vulnerabilities are identified and addressed.
  • This involves keeping an inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software in order to facilitate vulnerability and patch management.
• Public-facing web applications are protected against attacks.
  • This protection may be in the form of reviewing public-facing web applications with manual or automated application vulnerability security assessment tools at least every 12 months, or in the form of installing an automated solution in front of the public-facing web application that continually detects and prevents web-based attacks. A Web Application Firewall (WAF) is an example of the latter approach.
• Changes to all system components are managed securely.
  • This involves ensuring that all changes in production are made following a process that documents the reason for the change, who approved it, how to rollback in case of failure, etc.
  • Pre-production environments must be separated from production environments and the separation must be enforced with access controls.
  • Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements.

Example recommendations:

• If you use an Oracle database, ensure that any Critical Patch Updates are applied within 30 days.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

This requirement consists of the following sections:

• Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood.
• Access to system components and data is appropriately defined and assigned.
  • This involves reviewing all user accounts and related access privileges at least once every six months to ensure accesses remain appropriate based on job function.
  • User access to repositories of cardholder data must be restricted to ensure only the responsible administrators have access.
• Access to system components and data is managed via an access control system(s).

Requirement 8: Identify Users and Authenticate Access to System Components

This requirement consists of the following sections:

• Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.
• User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.
  • This involves ensuring that group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis.
  • Access for terminated users is immediately revoked.
  • Inactive accounts are removed or disabled within 90 days of inactivity.
• Strong authentication for users and administrators is established and managed.
  • All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
    • Something you know, such as a password or passphrase.
    • Something you have, such as a token device or smart card.
    • Something you are, such as a biometric element.
  • Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
  • If passwords are used, they are at least 12 characters in length and contain both numeric and alphabetic characters.
• Multi-factor authentication (MFA) is implemented to secure access into the CDE.
  • MFA must be implemented for all access into the CDE.
• Multi-factor authentication (MFA) systems are configured to prevent misuse.
  • MFA systems are implemented as follows:
    • The MFA system is not susceptible to replay attacks.
    • MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
    • At least two different types of authentication factors are used.
    • Success of all authentication factors is required before access is granted.
• Use of application and system accounts and associated authentication factors is strictly managed.
  • Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.

Example recommendations:

• If you use a relational database, no users with read-all access must exist.

Requirement 9: Restrict Physical Access to Cardholder Data

This requirement consists of the following sections:

• Processes and mechanisms for restricting physical access to cardholder data are defined and understood.
• Physical access controls manage entry into facilities and systems containing cardholder data.
  • Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms.
  • Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility.
  • Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the facility is restricted.
• Physical access for personnel and visitors is authorized and managed.
  • Visitors are escorted at all times.
  • Visitors are clearly identified and given a badge or other identification that expires.
  • Visitor badges or other identification visibly distinguishes visitors from personnel.
• Media with cardholder data is securely stored, accessed, distributed, and destroyed.
  • The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months.
  • Inventory logs of all electronic media with cardholder data are maintained.
  • Inventories of electronic media with cardholder data are conducted at least once every 12 months.
  • Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons.
  • Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons.
• Point of interaction (POI) devices are protected from tampering and unauthorized substitution.
  • A list of POI devices must be maintained.
  • POI devices must be inspected periodically to look for tampering or unauthorized substitution.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

This requirement consists of the following sections:

• Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.
• Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
  • Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts.
  • Audit logs capture all invalid logical access attempts.
• Audit logs are protected from destruction and unauthorized modifications.
  • Read access to audit logs files is limited to those with a job-related need.
  • Audit log files are protected to prevent modifications by individuals.
• Audit logs are reviewed to identify anomalies or suspicious activity.
  • The following audit logs are reviewed at least once daily:
    • All security events.
    • Logs of all system components that store, process, or transmit CHD and/or SAD.
    • Logs of all critical system components.
    • Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers).
• Audit log history is retained and available for analysis.
  • Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.
• Time-synchronization mechanisms support consistent time settings across all systems.
  • System clocks and time are synchronized using time-synchronization technology (e.g. Network Time Protocol).
  • Time synchronization settings and data are protected as follows:
    • Access to time data is restricted to only personnel with a business need.
    • Any changes to time settings on critical systems are logged, monitored, and reviewed.
• Failures of critical security control systems are detected, reported, and responded to promptly.
  • The following are examples of critical security control systems:
    • Network security controls.
    • Intrusion Detection Systems / Intrusion Prevention Systems.
    • Anti-malware solutions.
    • Physical access controls.
    • Audit logging mechanisms.
    • Audit log review mechanisms.
    • Automated security testing tools (if used).

Requirement 11: Test Security of Systems and Networks Regularly

This requirement consists of the following sections:

• Processes and mechanisms for regularly testing security of systems and networks are defined and understood.
• Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.
  • An inventory of authorized wireless access points is maintained, including a documented business justification.
• External and internal vulnerabilities are regularly identified, prioritized, and addressed.
  • Internal vulnerability scans are performed at least once every three months.
  • External vulnerability scans are performed at least once every three months by a PCI SSC-approved scanning vendor.
• External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.
  • Internal penetration testing is performed at least once every twelve months.
  • External penetration testing is performed at least once every twelve months.
• Network intrusions and unexpected file changes are detected and responded to.
  • All traffic is monitored at the perimeter of the CDE.
  • All traffic is monitored at critical points in the CDE.
  • A change-detection mechanism (for example, file integrity monitoring tools) is deployed to alert personnel to unauthorized modification of critical files and to perform critical file comparisons at least once weekly.
• Unauthorized changes on payment pages are detected and responded to.
  • A change- and tamper-detection mechanism is deployed to alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.

Requirement 12: Support Information Security with Organizational Policies and Programs

This requirement consists of the following sections:

• A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current.
• Acceptable use policies for end-user technologies are defined and implemented.
  • These policies instruct personnel on what they can and cannot do with company equipment and instruct personnel on correct and incorrect uses of company Internet and email resources.
• Risks to the cardholder data environment are formally identified, evaluated, and managed.
  • Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months.
• PCI DSS compliance is managed.
• PCI DSS scope is documented and validated.
  • An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.
  • PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment.
• Security awareness education is an ongoing activity.
  • A formal security awareness program is implemented to make all personnel aware of the entity’s information security policy and procedures, and their role in protecting the cardholder data.
  • Personnel receive security awareness training upon hire and at least once every 12 months.
• Personnel are screened to reduce risks from insider threats.
• Risk to information assets associated with third-party service provider (TPSP) relationships is managed.
  • A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.
  • A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
• Third-party service providers (TPSPs) support their customers’ PCI DSS compliance.
  • TPSPs support their customers’ requests for information by providing the following upon customer request:
    • PCI DSS compliance status information for any service the TPSP performs on behalf of customers.
    • Information about which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the customer, including any shared responsibilities.
• Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
  • An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident.
  • Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.
  • Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained on their incident response responsibilities.

Sources

• Official website of the PCI Security Standards Council:
  • https://www.pcisecuritystandards.org/pci_security/
• PCI Quick Reference Guide:
  • https://www.pcisecuritystandards.org/documents/pci_ssc_quick_guide.pdf
• Payment Card Industry Data Security Standard:
  • https://www.pcisecuritystandards.org/documents/PCI-DSS-v4_0.pdf
• Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation:
  • https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf
• Prioritized approach for PCI DSS:
  • https://www.pcisecuritystandards.org/documents/Prioritized-Approach-for-PCI-DSS-v3_2_1.pdf
• On the terms Category 1, 2 and 3:
  • https://pciguru.wordpress.com/2018/11/16/shared-services-aka-category-2-in-scope/
  • https://pciguru.wordpress.com/2013/05/26/pci-scoping-tool/
• SAQ Instructions and Guidelines:
  • https://www.pcisecuritystandards.org/documents/SAQ-InstrGuidelines-v3_2_1.pdf
• FAQ on using the SAQ eligibility criteria to determine onsite assessment requirements:
  • https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-SAQ-eligibility-criteria-be-used-for-determining-applicability-of-PCI-DSS-requirements-for-onsite-assessments
• FAQ on requirements for merchants that develop applications for consumer devices that accept payment card data:
  • https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/If-a-merchant-develops-an-application-that-runs-on-a-consumer-s-device-e-g-smartphone-tablet-or-laptop-that-is-used-to-accept-payment-card-data-what-are-the-merchant-s-obligations-regarding-PCI-DSS-and-PA-DSS-for-that-application
• Stripe’s guide for PCI compliance:
  • https://stripe.com/guides/pci-compliance
• PCI DSS and PA-DSS – Glossary of Terms, Abbreviations, and Acronyms:
  • https://www.pcisecuritystandards.org/documents/pci_glossary_v20.pdf
• About PCI compliance levels:
  • https://www.itgovernance.eu/blog/en/a-guide-to-the-4-pci-dss-compliance-levels
• Information Supplement: PCI DSS Tokenization Guidelines
  • https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
• About PCI DSS compliance in AWS Elasticache:
  • https://docs.amazonaws.cn/en_us/AmazonElastiCache/latest/red-ug/SelectEngine.html
  • https://aws.amazon.com/blogs/security/amazon-elasticache-redis-now-pci-dss-compliant-payment-card-data-in-memory/