Share This Article
Contents
For any company involved with credit card transactions, the Payment Card Industry Data Security Standard (PCI DSS) audit is the IT admin’s annual hurdle. In order to be compliant, system administrators need to make sure their networks are up to snuff. So, when approaching your PCI day (or weeks/months, in reality) of reckoning, it’s important to make sure you understand what you’re up against and how best to prepare.
Who Is Eligible?
The PCI DSS standards generally apply to anyone who accepts, transmits, or stores cardholder data. Essentially, anyone who takes credit card payments is subject to PCI DSS. However, the standards differ based on the number of transactions organizations process: the more transactions, the more rigorous the standards.
Eligible organizations are broken into four categories, or levels, based on how many credit card transactions they process per year. Level 1 is subject to the most rigorous standards, and Level 4 is subject to the least rigorous.
- Level 1: 6 million + transactions
- Level 2: 1-6 million transactions
- Level 3: 20 thousand -1 million transactions
- Level 4: Under 20K transactions
Does PCI DSS Apply to All Cards?
Technically, no. PCI DSS compliance is driven by credit card issuers. All major credit card issuers require PCI DSS compliance. These include:
- Visa
- Mastercard
- Discover
- American Express
- Japan Credit Bureau (JCB)
Other cards may choose to align with PCI DSS, or they may define their own set of rules. If your organization processes credit cards from other issuers, make sure you understand the issuer’s specified standards.
The 12 Requirements of PCI DSS Compliance
PCI DSS is defined by 12 main requirements of compliance, each of which has many subcategories and steps associated with it.
- Install and maintain network security controls.
- Apply secure configurations to all system components.
- Protect stored account data.
- Protect cardholder data with strong cryptography during transmission over open, public networks.
- Develop and maintain secure systems and software.
- Protect systems and software from malicious software.
- Restrict access to system components and cardholder data on a “need to know” basis.
- Identify users and authenticate access to system components.
- Restrict physical access to cardholder data.
- Log and monitor all access to system components and cardholder data.
- Test security systems and networks regularly.
- Maintain ongoing security with organizational policies and programs.
These 12 requirements can be broken down into six key objectives. Consider treating these six objectives as your overarching PCI DSS compliance goals as you develop your compliance plan.
- Secure networks and systems.
Make sure your groundwork is secure so that anything you do with payment info is done over a secure network and with secure systems. This includes both implementing and maintaining these elements. Requirements one and two fall under this objective:- 1. Install and maintain network security controls.
- 2. Apply secure configurations to all system components.
- Protect account data.
Protect the critical account and cardholder data, both in transit and at rest. This includes requirements three and four:- 3. Protect stored account data.
- 4. Protect cardholder data with strong cryptography during transmission over open, public networks.
- Ongoing vulnerability management
Protect the controls you put in place with ongoing vulnerability management. This includes requirements five and six:- 5. Develop and maintain secure systems and software.
- 6. Protect them from malicious software.
- Access control
Access control is one of the most important elements of security, as it both limits sanctioned access and reduces the chances of malicious access.- 7. Restrict access to system components and cardholder data by Need to Know.
- 8. Identify users and authenticate access to system components
- 9. Restrict physical access to cardholder data.
- Network monitoring and testing
Ensure ongoing security by monitoring and testing regularly.- 10. Log and monitor all access to system components and cardholder data.
- 11. Test security systems and networks regularly.
- Information security policies
This category embodies the final requirement:- 12. Maintain ongoing security with organizational policies and programs.
The PCI DSS Audit Process
When you start preparing for a PCI DSS audit, it’s helpful to know what to expect. This can help you define goals and benchmarks.
The PCI DSS standards outline six major steps to achieving compliance:
- Scope: Determine the scope of your PCI DSS assessment. Note that scope can be narrowed by segmenting the cardholder data environment (CDE) from the rest of the organization’s network. As the PCI DSS standards put it: “At a high level, adequate segmentation isolates systems that store, process, or transmit account data from those that do not.”
- Assess: Assess the environment’s alignment with PCI DSS standards.
- Report: Complete the applicable assessment report according to PCI DSS guidance and instructions. Read on to learn more.
- Attest: Complete the Attestation of Compliance (AoC) based on the findings in steps 2 and 3. Read on to learn more about AoCs.
- Submit documentation: This includes any SAQ, RoC, and AoC, as well as any other requested documentation.
- Remediate: If there were any identified gaps, work on remediating them so they end up in compliance with PCI DSS. Provide an updated report once remediated controls are in place.
SAQ
The self-assessment questionnaire (SAQ) is to be completed by the organization undergoing the PCI DSS audit. It’s designed to enable the organization to self-declare its compliance standing and means for accomplishing compliance.
Organizations that fall under Levels 2-4 must complete an SAQ, which can take the place of an external audit. Level 1 companies must instead undergo an external audit.
There are many different SAQs designed for different types of organizations. Review the different types to determine which SAQ is right for your organization.
RoC
The RoC, or Report on Compliance, is a reporting tool that documents the results of a PCI DSS assessment. The RoC is to be completed by an external Qualified Security Assessor (QSA) or an Internal Security Assessor (ISA), which is an internal employee who has received their ISA qualification through official PCI DSS training. The RoC is typically required for all Level 1 organizations and some Level 2 organizations.
AoC
The PCI Attestation of Compliance (AoC) is the PCI SSC form that attests to an organization’s compliance. The AoC can come from either the SAQ or the RoC.
Navigating PCI DSS Requirements
The 12 main requirements, outlined above, are broken down into several individual requirements. PCI DSS standards outline the following information for each requirement:
- Requirement: This specifies the rule or standard you must comply with. It is usually stated as a concise and strategic outcome.
Example (Requirement 1.3): “Network access to and from the cardholder data environment (CDE) is restricted.” - Defined Approach: PCI DSS standards grant you the flexibility to choose how you comply. As such, it lays out both a defined approach and a customized approach for each requirement. The defined approach specifies the means by which you must meet a requirement.
Example (Requirement 1.3): Inbound traffic to the CDE is restricted as follows:
A. To only traffic that is necessary.
B. All other traffic is specifically denied.
- Customized Approach: In contrast to the defined approach, the customized approach offers general guidelines for the requirement and allows you meet them however best suits your organization.
Example (Requirement 1.3): Unauthorized traffic cannot enter the CDE.
- Testing Procedure: The testing procedures state how the defined approach can be tested for compliance.
Example (Requirement 1.3):
- Examine configuration standards for network security controls (NSCs) to verify that they define restricting inbound traffic to the CDE is in accordance with all elements specified in this requirement.
- Examine configurations of NSCs to verify that inbound traffic to the CDE is restricted in accordance with all elements specified in this requirement.
- Guidance: The guidance section offers context, tips, and helpful information for each requirement.
Example (Requirement 1.3): The guidance for requirement 1.3 contains information regarding the requirement’s purpose, a summary of relevant good practices, and examples of how a rule might be configured to satisfy the requirement.
Start with Strong Fundamentals
The PCI DSS standards largely align with basic security best practices. Fortunately, you may already be doing many of them. If you have any identity and access management (IAM) solutions in place, for instance, you’re already equipped to comply with many of the PCI DSS standards.
Requirement 1.3, for example, specifies that the CDE should only be accessible to necessary traffic, and all other traffic should be specifically denied. With the right IAM solution, an organization could create a rule that denies all access to the CDE unless a user belongs to a specific user group for necessary CDE traffic.
A strong baseline of security and identity management will not only help you ace this audit, but it will also make compliance — with PCI DSS and other regulations — more painless in the future. That’s because many IT and security compliance principles are based on the same security fundamentals. Increasingly, these fundamentals align with Zero Trust security, a security approach that centers around the identity rather than the outdated physical perimeter. Learn more about Zero Trust security.
More Compliance Guidance for IT Professionals
IT compliance doesn’t always come naturally to IT professionals — but it does tend to fall on their plate at one time or another. To learn more about how to build the right foundation for ongoing compliance, tackle audits coming your way, and even take free a hands-on course to implement common compliance controls in your environment, check out JumpCloud’s IT Compliance Quickstart Guide.
