PCI DSS Compliance Certification: Best Practices

The Payment Card Industry Data Security Standard (PCI DSS) is a global framework of requirements that aim to protect cardholder data, including primary account numbers (PANs), cardholder names, expiry dates, and authentication data. Does your business wholly or partially involve storing, transmitting, or processing cardholder data to provide services? If so, your systems, processes, and people are in PCI DSS’s scope.

Becoming and staying compliant with this standard ensures that you’re applying reasonable security measures to protect this important information. Conversely, not adhering to this standard poses several risks, such as penalties, increased transaction fees, termination of service, liability, and loss of trust.

Implementing controls that satisfy the PCI DSS requirements is the way to become industry-compliant. Afterward, regular assessments need to be conducted to obtain the Attestation of Compliance (AoC) or Report of Compliance (RoC), depending on your business type.

Summary of best practices for PCI DSS compliance certification

PCI DSS merchant level categories

Before diving into the best practices, it’s essential to know how PCI DSS categorizes organizations—which the standard refers to as “merchants”—and what the high-level differences are in the compliance and oversight requirements.

For example, if you are a cryptocurrency startup providing a mobile application to enable trading services, and your client transactions sum up to around 300,000 annually, you would fall under Level 3. You would not need an external assessor. However, you still have to do self-assessments and quarterly vulnerability scans of the systems that touch cardholder data in any way. In the unfortunate event of a major breach—as defined by PCI DSS—your business’s classification will be amended to Level 1. 

Classification may also slide up or down for some businesses depending on market conditions that affect the volume of transactions. In our cryptocurrency startup example, a so-called “crypto winter” could decrease customers’ risk appetite and consequently the volume of transactions.

The world’s most sophisticated asset discovery and dependency for compliance and audit

Learn More

Discover assets automatically including hardware, software, and cloud infrastructure

Visualize application dependencies

Meet your compliance and audit requirements comprehensively and confidently

Get familiar with the 12 PCI DSS requirements

The PCI DSS principal requirements are grouped into six sections, making it easier to remember the main domains that must be addressed with internal controls. Additionally, detailed security requirements are available in the standard to give guidance on control implementation.

Section 1 – Build and Maintain a Secure Network and Systems

Requirement 1. Install and maintain network security controls. Network security controls (NSCs) refer to measures that protect the company’s network internally (e.g., by separating areas into different security zones) as well as keeping them safe from external, untrusted networks (e.g., through firewalls). Network policies should be enforced with security rules determining whether particular network traffic is allowed or denied.

Requirement 2. Apply secure configurations to all system components. Changing default passwords and disabling unnecessary services, functions, and accounts are all part of the secure configuration baseline that must be defined and implemented to protect the CDE. Companies are encouraged to use secure configuration best practices, such as the CIS benchmarks.

Section 2 – Protect Account Data

Requirement 3. Protect stored account data. Stored account data confidentiality needs to be preserved through encryption, masking, and truncation (e.g., PAN xxxx-xxxx-xxxx-1234). Also, storage should be kept to the minimum time necessary to perform related operations. These measures minimize the risks of a malicious actor being able to use cardholder data if they gain unauthorized access, as the data would be unreadable, incomplete, or already deleted.

Requirement 4. Protect cardholder data with strong cryptography during transmission over open, public networks. PAN transmission over untrusted networks (e.g., the internet) must be encrypted, period. In the case of internal network transmission, these networks need to be subject to risk assessments and must comply with other PCI DSS requirements.

Section 3 – Maintain a Vulnerability Management Program

Requirement 5. Protect all systems and networks from malicious software. Anti-malware solutions for systems, endpoints, browsers, and networks must be installed, configured, and monitored as part of effective vulnerability management efforts. Anti-malware software should be active on all systems, not just those determined to be at risk. In particular, processes and automated mechanisms should be in place to detect and protect personnel against phishing attacks and should run continuously.

Requirement 6. Develop and maintain secure systems and software. Internally developed applications should follow secure software development lifecycle principles, such as restricting access to source code, using secure coding practices—the OWASP Top 10 is a great reference—and performing independent testing before rollout. Your company should strive to obtain assurance that third-party systems follow the same requirements. As for the maintenance golden rule? Patch, patch, patch.

Section 4 – Implement Strong Access Control Measures

Requirement 7. Restrict access to system components and cardholder data by business need to know. Cardholder data access must be restricted to authorized personnel only. For this purpose, at least one access control mechanism needs to be established, and access control principles need to be defined and enforced by this mechanism. Principles like “need to know” and “least privilege” and models like “role-based access control” restrict actions that can be taken by users or other systems when interacting with the CDE.

Requirement 8. Identify users and authenticate access to system components. This requirement deals with the unique identification of users, processes, and systems and the secure authentication of those identities. In line with the previous requirements, access to identities should be strictly controlled, and authentication should be performed via multiple factors (MFA) in the CDE. Identity management provides accountability for any actions performed by an entity before, during, or after authentication.

Requirement 9. Restrict physical access to cardholder data. Yes, physical security is also a critical component in PCI DSS to the extent that physical areas contain systems managing or connected to the CDE. Therefore, the CDE and other sensitive areas, such as local network line entries, must be protected by physical access controls, intrusion detection systems, and environmental controls.

Section 5 – Regularly Monitor and Test Networks

Requirement 10. Log and monitor all access to system components and cardholder data. Audit logs should be implemented to support the detection and alerting of suspicious system activity. Ideally, logs should be collected centrally while dedicated staff monitors alerts and manages events and incidents. Additional controls are needed for time synchronization to ensure accurate service or security investigations into such events. To avoid any doubts, note that this requirement is not applicable to consumers (cardholders).

Requirement 11. Test the security of systems and networks regularly. A wide range of tests contribute to the assurance of working mechanisms and timely remediation of any vulnerabilities that might get exploited. These include penetration tests, vulnerability scans, review of policy rules for intrusion prevention systems (e.g., firewalls), wireless access point discovery, system testing as part of change management, and others. Note that vulnerability scans have strict criteria, as PCI DSS requires quarterly external scans performed by an Approved Scanning Vendor (ASV).

Section 6 – Maintain an Information Security Policy

Requirement 12. Support information security with organizational policies and programs. Finally, the last PCI DSS requirement is an information security policy that sets the direction for the whole organization’s information security program. The policy may act as a parent policy for other topic-specific policies, such as an acceptable use policy (AUP), network security policy, etc. These should be communicated internally, enforced, and kept up to date.

Identify which assets are in the PCI DSS scope

Once you know the PCI DSS 12 requirements, you should determine the scope of applicability for your organization. Remember that PCI DSS’s scope extends beyond systems to people and processes that can impact the cardholder data environment.

You should understand the boundaries between the CDE and other parts of your organization that do not interact with it. Having a system inventory is a great starting point. By continuously discovering and mapping your assets to the right systems and functions, you can ensure that your scope is always accurate, with a complete overview of your environment, including PCI DSS-related components. Automation plays a key role here, and products like Device42 provide centralized IT asset management and IT and cloud resources visibility.

Local inventory dashboard (source)

Design controls that map to PCI DSS requirements

There are two options for control design and implementation:

• The defined approach can be seen as a traditional approach, where controls will be designed and implemented just as they are stated in the PCI DSS standard. This approach suits companies new to PCI DSS that might need more direction. Compensating controls are allowed, provided that they follow the PCI DSS guidance.
• The customized approach, on the other hand, enables companies to stay flexible in their design and implementation as long as the requirements’ objectives are met. This works well with more mature, technology-innovative, or complex organizations.

Let’s look at an example of control design that follows the customized approach:

Note: The assessor of PCI DSS compliance will also examine compensating controls, exceptions, and non-applicable controls.

Implement and test controls

The next phase after control design is implementation. A gap assessment is the best tool to identify deviations between the design (the requirements) and the operation (the current situation). Conduct workshops with the operational teams that will own each control, and determine the necessary adjustments or new implementations. 

Remember to differentiate the CDE from the rest of the organization and apply controls proportionally based on internal risk assessments. For instance, you may want to look instantly at alerts from logs related to anomalous activity in a CDE system but may choose to review alerts from other systems once a day.

Control testing represents your self-assurance. Your QSA (if applicable) will also test your controls through examination, observation, and interview, but by the time you engage in the PCI DSS audit, you may want to already know where you stand. Testing your controls not only identifies operational issues before the actual audit but also allows you to continuously improve and minimize the chance of incidents.

Go through the SAQ or QSA process

If your organization is classified as Level 3 or 4, your compliance attestation will be based on a Self-Assessment Questionnaire (SAQ). A Qualified Security Assessor (QSA) is mandatory for Level 1 and optional for Level 2. Both the QSA and SAQ, as applicable, need to be repeated annually. Let’s see what these involve.

Self-Assessment Questionnaire (SAQ) process

The SAQ is designed to self-identify PCI DSS compliance status, evaluate existing security controls, and document compliance efforts. Several types of SAQ forms are tailored to various merchant environments and payment processing methods. 

The process involves five steps:

1. Determine eligibility: Based on your organization’s payment processing methods and CDE, identify the appropriate SAQ type.
2. Answer questions: Respond to each question in the SAQ, indicating whether your organization meets the specified PCI DSS requirements.
3. Implement controls: For any requirements not currently met, take corrective actions to implement the necessary security controls.
4. Attestation: Complete the Attestation of Compliance (AoC) included with the SAQ, affirming the accuracy of your responses and your organization’s compliance status.
5. Submission: Submit the completed SAQ and AoC to your acquiring bank or payment processor as required.

You are also free to consult a QSA and the PCI DSS itself for further guidance.

Qualified Security Assessor (QSA) process

During the on-site assessment, the QSA will require evidence samples related to the PCI DSS requirements. These may include a network diagram, change tickets, log retention data, SIEM and firewall security rules, lists of active users, risk assessments, incidents, user training materials, and more. One mandatory piece of evidence is the quarterly scan results.

A Report of Compliance (RoC) will be issued for the assessment against the PCI DSS requirements. The RoC is produced during onsite PCI DSS assessments as part of an organization’s validation process, and it provides reasonable assurance for compliance. It will include interview notes, control testing results, observations, documentation excerpts, screenshots, and any other information that contributes to the completeness of the report and the final verdict. Any findings will be justified in correlation to the provided evidence. 

Think of a very comprehensive audit report that must provide enough detail and coverage of the topic in order to draw a conclusion about the company’s posture. Since your goal is to get an attestation of compliance, make sure you provide complete and timely information to the QSA and clear up any doubts before the final report is issued.

Improve, monitor, and stay compliant

Your RoC or AoC is now ready—a major milestone in the PCI DSS compliance journey! If there are no gaps, findings, or observations then you can keep doing what you’re doing and continue testing controls on your own. Tips:

• Follow the PCI DSS requirements when you onboard any new systems that contribute to the CDE. 
• Keep your IT asset inventory up to date, including software, hardware, CIs, and cloud resources (such as containers and VMs). Track relationships among these to have a clear map of your CDE-related operations.
• Automate as many processes as possible to decrease errors and alert fatigue, and increase efficiency and audit readiness.

If your PCI DSS compliance document shows areas that need improvement, prioritize them and try to address them as soon as possible. An access control weakness, for example, will not only affect you in terms of PCI DSS compliance but may be a high risk to your organization and its clients overall.

Takeaway

Needless to say, compliance is not a one-time effort, and this includes PCI DSS. One of the prerequisites of a successful internal or external audit is data completeness and accuracy. For PCI DSS, this starts with the assets that contribute to making the CDE operational, available, and secure. Thus, having real-time, centralized information on every asset makes assessments, including control testing, run smoother and produce more trustworthy results. 

Whether you pursue PCI DSS compliance through a QSA—obtaining an Attestation of Compliance—or SAQ—obtaining a Report of Compliance—securing your environment through sound security controls as directed by the standard and its 12 requirements is key to a successful outcome.